[
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 6:00 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. My point was more
than Harfbuzz is the gold standard, and JDK 9 will provide that, so we know
we're on a great trajectory. 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
> 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.
> 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: [email protected]
For additional commands, e-mail: [email protected]
