PDFBox
  1. PDFBox
  2. PDFBOX-490

Pdf Printing of text from embedded fonts

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.8.0-incubator
    • Fix Version/s: 2.0.0
    • Component/s: FontBox
    • Labels:
      None
    • Environment:
      Windows XP, JRE 1.6

      Description

      When printing from utility PrintPdf, text is rendered in the wrong typeface. The correct typeface is embedded within the PDF (Embedded Subset) as a TrueType font with an ANSI encoding. It may be noted that the AcroFields in a Courier typeface render correctly.

      1. filled.pdf
        235 kB
        Steve Poling
      2. TestTTFGlyph.java
        6 kB
        Andreas Lehmkühler

        Issue Links

          Activity

          Hide
          Andreas Lehmkühler added a comment -

          I added rendering for TTF fonts in revision 1506667.

          This should solve a lot of problems, but there are still some minor issues left. I'll create some new JIRAs for those. In a couple of days I'll start to clean the linked JIRAs.

          Thanks to all who helped me to get this done!

          Show
          Andreas Lehmkühler added a comment - I added rendering for TTF fonts in revision 1506667. This should solve a lot of problems, but there are still some minor issues left. I'll create some new JIRAs for those. In a couple of days I'll start to clean the linked JIRAs. Thanks to all who helped me to get this done!
          Hide
          Andreas Lehmkühler added a comment -

          I fixed some minor fontbox issues in revision 1506164:

          • fixed the CMap format 2 parser
          • added 2 new platform constants
          • fixed the table check of the TTFParser (CID fonts may omit CMap tables)
          • removed the Glyph2D class (the implementation will be moved to pdfbox)

          More to come, stay tuned ...

          Show
          Andreas Lehmkühler added a comment - I fixed some minor fontbox issues in revision 1506164: fixed the CMap format 2 parser added 2 new platform constants fixed the table check of the TTFParser (CID fonts may omit CMap tables) removed the Glyph2D class (the implementation will be moved to pdfbox) More to come, stay tuned ...
          Hide
          Sindhu N Kashyap added a comment -

          Hi,

          Has the embedded font issue been addressed and resolved in the next verion of pdfbox 1.7?

          Show
          Sindhu N Kashyap added a comment - Hi, Has the embedded font issue been addressed and resolved in the next verion of pdfbox 1.7?
          Hide
          Andreas Lehmkühler added a comment -

          I added a workaround in revision 1413782. It solves the issue with the attached file, BUT it doesn't work in every case. It uses the new TTFSubfont support of fontbox (see PDFBOX-922) to rebuild the embedded font. It is limited to WinANSI fonts which doesn't contain a naming table. I guess it'll be easy to integrate Juraj idea about rebuilding a missing cmap table.

          Show
          Andreas Lehmkühler added a comment - I added a workaround in revision 1413782. It solves the issue with the attached file, BUT it doesn't work in every case. It uses the new TTFSubfont support of fontbox (see PDFBOX-922 ) to rebuild the embedded font. It is limited to WinANSI fonts which doesn't contain a naming table. I guess it'll be easy to integrate Juraj idea about rebuilding a missing cmap table.
          Hide
          Juraj Lonc added a comment -
          Show
          Juraj Lonc added a comment - OK I attached it here: https://issues.apache.org/jira/browse/PDFBOX-1397
          Hide
          Andreas Lehmkühler added a comment -

          Of course, we are interested!

          The easiest way would be a patch. If you are not sure how to integrate your solution into PDFBox, you should just attach the PoC and we'll work together to integrate it.

          IMO this would be just a temporarily workaround. In the long run we have to load and render all fonts on our own, as most of them are not supported by java directly. So your solution would buy us some valuable time and would ease the pain we have handling those embedded fonts.

          To make a long story short, I really appreciate your offer and can't wait to get a hand on it

          Show
          Andreas Lehmkühler added a comment - Of course, we are interested! The easiest way would be a patch. If you are not sure how to integrate your solution into PDFBox, you should just attach the PoC and we'll work together to integrate it. IMO this would be just a temporarily workaround. In the long run we have to load and render all fonts on our own, as most of them are not supported by java directly. So your solution would buy us some valuable time and would ease the pain we have handling those embedded fonts. To make a long story short, I really appreciate your offer and can't wait to get a hand on it
          Hide
          Juraj Lonc added a comment -

          i made "proof of concept" java class (without changing a letter in pdfbox sources).
          embedded fonts and converting pdf to image works fine

          It works this way:
          1. find pdfonts in pdf
          2. if pdfont has stream (=embedded font) then read it
          3. get unicode chars mapping from pdfont (=cmap)
          4. insert cmap into embedded font
          5. replace stream in pdfont

          it looks complicated, but in fact it is not too much.

          are you interested in implementing it into pdfbox?

          Show
          Juraj Lonc added a comment - i made "proof of concept" java class (without changing a letter in pdfbox sources). embedded fonts and converting pdf to image works fine It works this way: 1. find pdfonts in pdf 2. if pdfont has stream (=embedded font) then read it 3. get unicode chars mapping from pdfont (=cmap) 4. insert cmap into embedded font 5. replace stream in pdfont it looks complicated, but in fact it is not too much. are you interested in implementing it into pdfbox?
          Hide
          Juraj Lonc added a comment -

          I don't think that problem is in missing "post" (PostScript) data in embedded font.

          IMHO the problem is that "cmap" table is missing.

          Of course I have tested that. When I remove "cmap" from proper font, JRE is not able to load/use that font. When I remove "post" from proper font, JRE is able to load/use that font.

          Show
          Juraj Lonc added a comment - I don't think that problem is in missing "post" (PostScript) data in embedded font. IMHO the problem is that "cmap" table is missing. Of course I have tested that. When I remove "cmap" from proper font, JRE is not able to load/use that font. When I remove "post" from proper font, JRE is able to load/use that font.
          Hide
          Andreas Lehmkühler added a comment -

          The conversion of simple glyphs into a GeneralPath works quite good, but there are still some issues with composite glyphs.
          Find attached a simple piece of code to test the conversion. It draws every glyph of a given font and creates a png pic of them.
          Any comments and improvements are welcome

          Show
          Andreas Lehmkühler added a comment - The conversion of simple glyphs into a GeneralPath works quite good, but there are still some issues with composite glyphs. Find attached a simple piece of code to test the conversion. It draws every glyph of a given font and creates a png pic of them. Any comments and improvements are welcome
          Hide
          Andreas Lehmkühler added a comment -

          I added a new class to convert a TTF-glyph into an AWT-GeneralPath in revision 1340655

          Show
          Andreas Lehmkühler added a comment - I added a new class to convert a TTF-glyph into an AWT-GeneralPath in revision 1340655
          Hide
          Andreas Lehmkühler added a comment -

          I fixed some problems to avoid an OutOfMemoryException in revision 1326311 including a patch proposed by Eric Leleu, see PDFBOX-1265 for details.

          Embedded subsets only contains a subset of glyphs, but nevertheless their head-table may still pretend to consist of all glyphs. Just stop reading glyphs if the end of the glyph table is reached solves the issue.

          Show
          Andreas Lehmkühler added a comment - I fixed some problems to avoid an OutOfMemoryException in revision 1326311 including a patch proposed by Eric Leleu, see PDFBOX-1265 for details. Embedded subsets only contains a subset of glyphs, but nevertheless their head-table may still pretend to consist of all glyphs. Just stop reading glyphs if the end of the glyph table is reached solves the issue.
          Hide
          Andreas Lehmkühler added a comment -

          I improved the TTFReader (in revisons 1311300 and 1311314 ) to read the glyph information which is needed to render them.

          The implementation is based on some batik code which is a subproject of Apache XML Graphics Project [1], [2]

          The next step will be to implement some code to render the read information. I already started with that and it looks promising.

          [1] http://xmlgraphics.apache.org/batik/
          [2] http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/sources/org/apache/batik/svggen/font/table/

          Show
          Andreas Lehmkühler added a comment - I improved the TTFReader (in revisons 1311300 and 1311314 ) to read the glyph information which is needed to render them. The implementation is based on some batik code which is a subproject of Apache XML Graphics Project [1] , [2] The next step will be to implement some code to render the read information. I already started with that and it looks promising. [1] http://xmlgraphics.apache.org/batik/ [2] http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/sources/org/apache/batik/svggen/font/table/
          Hide
          Andreas Lehmkühler added a comment -

          All suggested solutions are based on font substitution which is already part of PDFBox and will only work in very special cases.

          IMHO the one and only solution is to implement a TTF reader to read all necessary information to create glyphs on our own. I'm doing some progess using some batik code. I hope there will be more soon.

          Show
          Andreas Lehmkühler added a comment - All suggested solutions are based on font substitution which is already part of PDFBox and will only work in very special cases. IMHO the one and only solution is to implement a TTF reader to read all necessary information to create glyphs on our own. I'm doing some progess using some batik code. I hope there will be more soon.
          Hide
          Valerio Santinelli added a comment -

          Is there any news about this bug? I'm experiencing this same issue with version 1.6.0 of PDFBox and it looks like it's still because of Embedded Subset fonts.

          Show
          Valerio Santinelli added a comment - Is there any news about this bug? I'm experiencing this same issue with version 1.6.0 of PDFBox and it looks like it's still because of Embedded Subset fonts.
          Hide
          John Manko added a comment -

          Jens, I applied your changes to the latest pdfbox svn truck (as of today), and I'm still getting a similar problem. I was wondering if you can advise. Here is the warning (which results in a printed document where the font type is changed and other odd problems such as spaces modified to contain other characters and bullet numbers changed to strange characters):

          Sep 16, 2011 3:07:27 PM org.apache.pdfbox.pdmodel.font.PDSimpleFont drawString
          WARNING: Changing font on <T> from <Liberation Serif Bold> to the default font

          I'm running Ubuntu 11.04, and the PDF was originally created in OpenOffice.org.

          Here are the fonts used by the PDF:

          LiberationSerif-Bold
          TrueType
          Embedded subset

          LiberationSerif
          TrueType
          Embedded subset

          Courier10PitchBT-Bold
          TrueType
          Embedded

          Courier10PitchBT-Roman
          TrueType
          Embedded

          This is my version of the JVM:

          $ java -version
          java version "1.6.0_22"
          OpenJDK Runtime Environment (IcedTea6 1.10.2) (6b22-1.10.2-0ubuntu1~11.04.1)
          OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

          I've also testing using Sun HotSpot JVM, but the issue occurs. Here is that version:

          $ /usr/lib/jvm/java-6-sun/bin/java -version
          java version "1.6.0_26"
          Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
          Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

          Show
          John Manko added a comment - Jens, I applied your changes to the latest pdfbox svn truck (as of today), and I'm still getting a similar problem. I was wondering if you can advise. Here is the warning (which results in a printed document where the font type is changed and other odd problems such as spaces modified to contain other characters and bullet numbers changed to strange characters): Sep 16, 2011 3:07:27 PM org.apache.pdfbox.pdmodel.font.PDSimpleFont drawString WARNING: Changing font on <T> from <Liberation Serif Bold> to the default font I'm running Ubuntu 11.04, and the PDF was originally created in OpenOffice.org. Here are the fonts used by the PDF: LiberationSerif-Bold TrueType Embedded subset LiberationSerif TrueType Embedded subset Courier10PitchBT-Bold TrueType Embedded Courier10PitchBT-Roman TrueType Embedded This is my version of the JVM: $ java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.2) (6b22-1.10.2-0ubuntu1~11.04.1) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) I've also testing using Sun HotSpot JVM, but the issue occurs. Here is that version: $ /usr/lib/jvm/java-6-sun/bin/java -version java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
          Hide
          Jens Bruhn added a comment -

          forgot to mention the init()-method, which should be called by constructor:

          private void init()
          {
          final GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
          final String[] fontFamilies = ge.getAvailableFontFamilyNames();

          for (final String fontFamily : fontFamilies)

          { final String fontName = fontFamily.toLowerCase().replaceAll(" ", ""); _normalizedFontNameSet.put(fontName, fontFamily); }

          }

          Show
          Jens Bruhn added a comment - forgot to mention the init()-method, which should be called by constructor: private void init() { final GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); final String[] fontFamilies = ge.getAvailableFontFamilyNames(); for (final String fontFamily : fontFamilies) { final String fontName = fontFamily.toLowerCase().replaceAll(" ", ""); _normalizedFontNameSet.put(fontName, fontFamily); } }
          Hide
          Jens Bruhn added a comment -

          My own workaround is attached. If someone has a better workaround or some more ideas, I would really like to see them here.

          It still doesn't work for special characters with "Symbol"-Font (created with LibreOffice PDF-Export). Any ideas?

          Greetings,
          jens

          Class PDTrueTypeFont:

          private final Map<String, String> _normalizedFontNameSet = new HashMap<String, String>();
          private final Map<String, Font> _fontCache = new HashMap<String, Font>();

          @Override
          public Font getawtFont() throws IOException
          {
          PDFontDescriptorDictionary fd = (PDFontDescriptorDictionary) getFontDescriptor();
          final String fontName = fd.getFontName();

          if (_fontCache.keySet().contains(fontName))

          { awtFont = _fontCache.get(fontName); }

          else
          {
          final String fontAndStyle = fontName.substring(fontName.indexOf("+") + 1, fontName.length() - 2);
          final String pureFontName = fontAndStyle.contains("") ? fontAndStyle.substring(0, fontAndStyle.indexOf(""))
          : fontAndStyle;
          final String pureStyleName = fontAndStyle.contains("") ? fontAndStyle.substring(fontAndStyle.indexOf("") + 1) : "";
          int style = 0;

          if (pureStyleName.toLowerCase().contains("bold"))

          { style |= Font.BOLD; }

          if (pureStyleName.toLowerCase().contains("italic"))

          { style |= Font.ITALIC; }

          final String newFontName = getLocalFontName(pureFontName);
          awtFont = new Font(newFontName == null ? "Arial" : newFontName, style, 10);
          _fontCache.put(fontName, awtFont);
          }

          return awtFont;
          }

          private String getLocalFontName(final String name)
          {
          final Iterator<String> iterator = _normalizedFontNameSet.keySet().iterator();
          final String compareName = name.toLowerCase();
          String result = null;

          while (iterator.hasNext())
          {
          final String fontName = iterator.next();

          if (compareName.contains(fontName))

          { result = _normalizedFontNameSet.get(fontName); break; }

          }

          return result;
          }

          Show
          Jens Bruhn added a comment - My own workaround is attached. If someone has a better workaround or some more ideas, I would really like to see them here. It still doesn't work for special characters with "Symbol"-Font (created with LibreOffice PDF-Export). Any ideas? Greetings, jens Class PDTrueTypeFont: private final Map<String, String> _normalizedFontNameSet = new HashMap<String, String>(); private final Map<String, Font> _fontCache = new HashMap<String, Font>(); @Override public Font getawtFont() throws IOException { PDFontDescriptorDictionary fd = (PDFontDescriptorDictionary) getFontDescriptor(); final String fontName = fd.getFontName(); if (_fontCache.keySet().contains(fontName)) { awtFont = _fontCache.get(fontName); } else { final String fontAndStyle = fontName.substring(fontName.indexOf("+") + 1, fontName.length() - 2); final String pureFontName = fontAndStyle.contains(" ") ? fontAndStyle.substring(0, fontAndStyle.indexOf(" ")) : fontAndStyle; final String pureStyleName = fontAndStyle.contains(" ") ? fontAndStyle.substring(fontAndStyle.indexOf(" ") + 1) : ""; int style = 0; if (pureStyleName.toLowerCase().contains("bold")) { style |= Font.BOLD; } if (pureStyleName.toLowerCase().contains("italic")) { style |= Font.ITALIC; } final String newFontName = getLocalFontName(pureFontName); awtFont = new Font(newFontName == null ? "Arial" : newFontName, style, 10); _fontCache.put(fontName, awtFont); } return awtFont; } private String getLocalFontName(final String name) { final Iterator<String> iterator = _normalizedFontNameSet.keySet().iterator(); final String compareName = name.toLowerCase(); String result = null; while (iterator.hasNext()) { final String fontName = iterator.next(); if (compareName.contains(fontName)) { result = _normalizedFontNameSet.get(fontName); break; } } return result; }
          Hide
          Jonathan Levinson added a comment -

          Hi Sergey,

          I would like more detailed information - a diff/patch for the code you added in your comment of 02/May/11.

          Also, pardon my ignorance, but what do you mean by you may include some popular fonts into your program distribution and load them into some static map.

          Does this mean we need a special build of PDFBox that includes the fonts we wish to use? Or is there some way of specifying the fonts dynamically even though they are not built together with PDFBox.

          I'm a newbie to this area, so I'm sorry if my questions seem elementary.

          Thanks,
          Jonathan Levinson

          Show
          Jonathan Levinson added a comment - Hi Sergey, I would like more detailed information - a diff/patch for the code you added in your comment of 02/May/11. Also, pardon my ignorance, but what do you mean by you may include some popular fonts into your program distribution and load them into some static map. Does this mean we need a special build of PDFBox that includes the fonts we wish to use? Or is there some way of specifying the fonts dynamically even though they are not built together with PDFBox. I'm a newbie to this area, so I'm sorry if my questions seem elementary. Thanks, Jonathan Levinson
          Hide
          Sergey Vladimirov added a comment -

          I would like to see fix for this bug as soon as possible...

          But for people who need workaround, there is one "hack": you can alter PDTrueTypeFont::getawtFont() code to always replace embedded font with some another font. For example, you can include some popular fonts into your program distribution, load them into some static map and use it like:

          if (awtFont != null) {
          String name = awtFont.getName();
          Font replace = FontsHelper.getHelperFont(name);
          if (replace != null)

          { log.debug("Replace embedded font '" + name + "' with env. provided"); awtFont = replace; }

          }

          This way page shows nicely. Of course, all fonts from this page shall be included in your program distribution, and can be done only for well-known fonts like OpenSymbol or Liberation, and you shall be aware of fonts license problems and etc., but at least it works.

          (if you need more detailed information, like diff/patch, leave me a comment)

          Show
          Sergey Vladimirov added a comment - I would like to see fix for this bug as soon as possible... But for people who need workaround, there is one "hack": you can alter PDTrueTypeFont::getawtFont() code to always replace embedded font with some another font. For example, you can include some popular fonts into your program distribution, load them into some static map and use it like: if (awtFont != null) { String name = awtFont.getName(); Font replace = FontsHelper.getHelperFont(name); if (replace != null) { log.debug("Replace embedded font '" + name + "' with env. provided"); awtFont = replace; } } This way page shows nicely. Of course, all fonts from this page shall be included in your program distribution, and can be done only for well-known fonts like OpenSymbol or Liberation, and you shall be aware of fonts license problems and etc., but at least it works. (if you need more detailed information, like diff/patch, leave me a comment)
          Hide
          Bill Janssen added a comment -

          You can find another image that PDFBox 1.5.0 PDFToImage fails miserably on at http://www.lavasurfer.com/100akerpathology.pdf. In general, I find this a useful short test page, as it has so many elements: images, tables, references, vertical text, etc.

          Show
          Bill Janssen added a comment - You can find another image that PDFBox 1.5.0 PDFToImage fails miserably on at http://www.lavasurfer.com/100akerpathology.pdf . In general, I find this a useful short test page, as it has so many elements: images, tables, references, vertical text, etc.
          Hide
          Andreas Lehmkühler added a comment -

          After doing some font stuff I came to the conclusion, that it might be easier to follow solution 2. The following things have to be done:

          • improve the TTFParser to read the glyph data
          • adapt the CFF2Type1 code so that it is possible to create a type1 font using the TTF data
          Show
          Andreas Lehmkühler added a comment - After doing some font stuff I came to the conclusion, that it might be easier to follow solution 2. The following things have to be done: improve the TTFParser to read the glyph data adapt the CFF2Type1 code so that it is possible to create a type1 font using the TTF data
          Hide
          Alexander Geist added a comment -

          Still not fixed in current snapshot of version 1.4.0

          Show
          Alexander Geist added a comment - Still not fixed in current snapshot of version 1.4.0
          Hide
          Joshua Marquart added a comment - - edited

          Is there a workaround for this issue, or is there at least a way to detect whether a PDF has these embedded fonts in order to flag the file as a potential problem prior to processing?

          Show
          Joshua Marquart added a comment - - edited Is there a workaround for this issue, or is there at least a way to detect whether a PDF has these embedded fonts in order to flag the file as a potential problem prior to processing?
          Hide
          Friedrich-Carl Gneisenau added a comment -

          In 1.1.0 it seems not be fixed. I have the same problem with a report. Here the given Fonttype is Arial (embedded).

          Has anyone a work around for this problem. It's very urgend.

          Show
          Friedrich-Carl Gneisenau added a comment - In 1.1.0 it seems not be fixed. I have the same problem with a report. Here the given Fonttype is Arial (embedded). Has anyone a work around for this problem. It's very urgend.
          Hide
          Colin Bell added a comment -

          Are there any known work arounds at this time? I really need to find a way round this issue.

          Show
          Colin Bell added a comment - Are there any known work arounds at this time? I really need to find a way round this issue.
          Hide
          dennis verdaasdonk added a comment -

          Hi there,
          is there any update on this item?
          i was hoping it was sorted in the newest version, 1.1.0, but pitty enough it was not in yet.
          let me know.
          thanks
          dennis

          Show
          dennis verdaasdonk added a comment - Hi there, is there any update on this item? i was hoping it was sorted in the newest version, 1.1.0, but pitty enough it was not in yet. let me know. thanks dennis
          Hide
          Andreas Lehmkühler added a comment -

          The java font loader complains about the missing name table, so that I tried to add that one. To do so, we have to implement a TTF writer. There are already some classes [1] from the TTFParser which can be used.

          [1] http://svn.eu.apache.org/viewvc/pdfbox/fontbox/trunk/src/main/java/org/apache/fontbox/ttf/

          Show
          Andreas Lehmkühler added a comment - The java font loader complains about the missing name table, so that I tried to add that one. To do so, we have to implement a TTF writer. There are already some classes [1] from the TTFParser which can be used. [1] http://svn.eu.apache.org/viewvc/pdfbox/fontbox/trunk/src/main/java/org/apache/fontbox/ttf/
          Hide
          Steve Poling added a comment -

          I just took inventory of the tables used in the TTF data embedded in the PDF attached to PDFBOX-490 and compared it with the TTF file from which the data originated. I found that the following tables are omitted: hdmx (horizonal device metrics), name, and post (glyph name and postscript compatibility).

          Have you attempted adding any of these tables to the TTF stream? I suppose the easiest would be the name table, then post, then hdmx. I note the TTF documentation requires the name and post tables, but not the hdmx, so I suppose I might get by without that.

          Is there anything in the pdfbox codebase that reads/writes TTF files?

          Show
          Steve Poling added a comment - I just took inventory of the tables used in the TTF data embedded in the PDF attached to PDFBOX-490 and compared it with the TTF file from which the data originated. I found that the following tables are omitted: hdmx (horizonal device metrics), name, and post (glyph name and postscript compatibility). Have you attempted adding any of these tables to the TTF stream? I suppose the easiest would be the name table, then post, then hdmx. I note the TTF documentation requires the name and post tables, but not the hdmx, so I suppose I might get by without that. Is there anything in the pdfbox codebase that reads/writes TTF files?
          Hide
          Andreas Lehmkühler added a comment -

          I've worked on option (1) but it's more complicated than I thought at first. At the moment I'm working on PDFBOX-542 which will add support for CFF/Type2 fonts to fontbox. As java doesn't support that font format, those fonts will be converted to a Type1 font which is supported by java. Returning to our issue with embedded subsets of true type fonts, this will be a suitable solution too.

          Show
          Andreas Lehmkühler added a comment - I've worked on option (1) but it's more complicated than I thought at first. At the moment I'm working on PDFBOX-542 which will add support for CFF/Type2 fonts to fontbox. As java doesn't support that font format, those fonts will be converted to a Type1 font which is supported by java. Returning to our issue with embedded subsets of true type fonts, this will be a suitable solution too.
          Hide
          Andreas Lehmkühler added a comment -

          I've to correct my former guess. First off all the problem is the missing Naming-Table.

          I think there are two possible options to solve this issue. In both cases we have to improve the TTFParser.

          (1) repair the incomplete stream before passing it to the createFont method
          (2) create an awtfont on our own with the provided data from the embedded fontdata

          I guess (1) will be easier. Any other ideas?

          Show
          Andreas Lehmkühler added a comment - I've to correct my former guess. First off all the problem is the missing Naming-Table. I think there are two possible options to solve this issue. In both cases we have to improve the TTFParser. (1) repair the incomplete stream before passing it to the createFont method (2) create an awtfont on our own with the provided data from the embedded fontdata I guess (1) will be easier. Any other ideas?
          Hide
          Andreas Lehmkühler added a comment -

          I guess the streams for the fonts (embedded subset) aren't complete. The PostScriptTable is missing and obviously java needs it to create an awt-font from a truetype-font (see java.awt.Font.createFont). otherwise a FontFormatException is thrown.

          Does anyone know a workaround? Or do we have to implement a ttf-streamwriter to create a repaired ttf-stream?

          Show
          Andreas Lehmkühler added a comment - I guess the streams for the fonts (embedded subset) aren't complete. The PostScriptTable is missing and obviously java needs it to create an awt-font from a truetype-font (see java.awt.Font.createFont). otherwise a FontFormatException is thrown. Does anyone know a workaround? Or do we have to implement a ttf-streamwriter to create a repaired ttf-stream?
          Hide
          Steve Poling added a comment -

          This file illustrates the problem. Please let me know if attaching the TTF files used to generate this PDF would prove helpful.

          Show
          Steve Poling added a comment - This file illustrates the problem. Please let me know if attaching the TTF files used to generate this PDF would prove helpful.

            People

            • Assignee:
              Andreas Lehmkühler
              Reporter:
              Steve Poling
            • Votes:
              22 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development