[ https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633639#comment-15633639 ]
John Hewson edited comment on PDFBOX-3550 at 11/3/16 5:59 PM: -------------------------------------------------------------- > One limitation we need to be aware of is that not all of art works on Android. I think we're ok here. Android already ships with Harfbuzz, so writing a JNI wrapper to provide a GlyphVector API should be fairly straightforward, especially as PDFBox should only need one or two methods of GlyphVector. What would really help for porting is to not expose GlyphVector in our public API, so there's no hard public dependency on AWT. > What I currently don't understand is how we get from a GlyphVector to a > typical content stream maybe you can elaborate on that a bit. We can use AWT to handle OpenType shaping via Font.layoutGlyphVector(..) which takes a Unicode string and returns a GlyphVector containing the final positioned glyphs. So we start of with a Unicode string and end up with an array of (GID, dx, dy) tuples. This is separate from any higher-level text layout such as line breaking, justification, word-wrap, etc., which AWT provides via TextLayout and which we may or may not want to use in PDFBox. So we'll end up with three layers: - high-level text layout - OpenType shaping - writing glyphs to a content stream > My current preference would be to work with the FOP people on that topic. At > least the enhanced OpenType support would be something we can jointly work on > and put it into FontBox. I'm not so sure about this, how much do you know about Indic scripts? or Arabic? or Thai? These are not easy things, in fact the creator of Harfbuzz [warns against it|https://github.com/nodebox/opentype.js/issues/19#issuecomment-35935072] - IBM abandoned ICU’s complex text layout, as did FreeType. Pango and Qt joined forces to make Harfbuzz. I should emphasise that Harfbuzz is going to be powering AWT's GlyphVector in JDK 9, not a new API, so there's no need to force an upgrade. Complex text layout has been available in GlyphVector since JDK 1.4, and while not perfect, seems to work just fine. I have more than a few reservation's about FOP's code and its bugs (FOP-2355, FOP-2092, FOP-2210, FOP-2454), for more details see my reply to Tilman above. was (Author: jahewson): > One limitation we need to be aware of is that not all of art works on Android. I think we're ok here. Android already ships with Harfbuzz, so writing a JNI wrapper to provide a GlyphVector API should be fairly straightforward, especially as PDFBox should only need one or two methods of GlyphVector. What would really help for porting is to not expose GlyphVector in our public API, so there's no hard public dependency on AWT. > What I currently don't understand is how we get from a GlyphVector to a > typical content stream maybe you can elaborate on that a bit. We can use AWT to handle OpenType shaping via Font.layoutGlyphVector(..) which takes a Unicode string and returns a GlyphVector containing the final positioned glyphs. So we start of with a Unicode string and end up with an array of (GID, dx, dy) tuples. This is separate from any higher-level text layout such as line breaking, justification, word-wrap, etc., which AWT provides via TextLayout and which we may or may not want to use in PDFBox. So we'll end up with three layers: - high-level text layout - OpenType shaping - writing glyphs to a content stream > At least the enhanced OpenType support would be something we can jointly work > on and put it into FontBox. I'm not so sure about this, how much do you know about Indic scripts? or Arabic? or Thai? These are not easy things, in fact the creator of Harfbuzz [warns against it|https://github.com/nodebox/opentype.js/issues/19#issuecomment-35935072] - IBM abandoned ICU’s complex text layout, as did FreeType. Pango and Qt joined forces to make Harfbuzz. I should emphasise that Harfbuzz is going to be powering AWT's GlyphVector in JDK 9, not a new API, so there's no need to force an upgrade. Complex text layout has been available in GlyphVector since JDK 1.4, and while not perfect, seems to work just fine. I have more than a few reservation's about FOP's code and its bugs (FOP-2355, FOP-2092, FOP-2210, FOP-2454), for more details see my reply to Tilman above. > OpenType Shaping > ---------------- > > Key: PDFBOX-3550 > URL: https://issues.apache.org/jira/browse/PDFBOX-3550 > Project: PDFBox > Issue Type: New Feature > Components: FontBox, PDModel > Environment: All > Reporter: Omid Pourhadi > Labels: unicode > Attachments: BYekan.ttf > > > the problem is, in some languages letters need to be joined together for > example, consider this word > {color:red} > سلام > {color} > but after creating a pdf it contorts to > {color:red} > سلام > {color} > with extra semi-spaces. I think this is a bug in pdfbox and definetly is not > related to font. > {code:title=SampleCode.java|borderStyle=solid} > public class SampleCode > { > public static void main(String[] args) throws IOException > { > > PDDocument document = new PDDocument(); > //this font perfectly works in iText and JasperReport with the same text > PDFont titleFont = PDType0Font.load(document, > SampleCode.class.getResourceAsStream("/BYekan.ttf")); > PDPage page = new PDPage(PDRectangle.A4); > document.addPage(page); > PDPageContentStream contentStream = new PDPageContentStream(document, > page); > contentStream.beginText(); > contentStream.setFont(titleFont, 12); > contentStream.newLineAtOffset(0, 100); > contentStream.showText("سلام"); > contentStream.endText(); > contentStream.close(); > > > document.save(new File("/home/omidp/temp/htmltopdf/output.pdf")); > document.close(); > } > } > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org