[
https://issues.apache.org/jira/browse/PDFBOX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15633639#comment-15633639
]
John Hewson commented on PDFBOX-3550:
-------------------------------------
> 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 elsewhere 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
