[
https://issues.apache.org/jira/browse/FOP-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15507202#comment-15507202
]
Simone Rondelli commented on FOP-1969:
--------------------------------------
GlyphSequence is already using an IntBuffer to store the characters. Did you
mean MultiByteFont? This would mean to change lot of interfaces such as
Substitutable and Positionable and their subclasses (Font, MultiByteFont,
CustomFontMetricMapper, LazyFont). Is this what you want?
Regardless the answer of the previous question it's still not cleat to me why
to use {{findCharacterFromGlyphIndex(gi);}} instead of using the characters
inside GlyphSequence.
> Surrogate pairs not treated as single unicode codepoint for display purposes
> ----------------------------------------------------------------------------
>
> Key: FOP-1969
> URL: https://issues.apache.org/jira/browse/FOP-1969
> Project: FOP
> Issue Type: Improvement
> Components: unqualified
> Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
> Reporter: Glenn Adams
> Attachments: Urdu.zip, pcltest.zip, single-byte.zip, testing.fo,
> testing.fo, testing.pdf, testing.pdf, testing.xml, testing.xsl, tiffttc.zip
>
>
> unicode codepoints outside of the BMP (base multilingual plane), i.e., whose
> scalar value is greater than 0xFFFF (65535), are coded as UTF-16 surrogate
> pairs in Java strings, which pair should be treated as a single codepoint for
> the purpose of mapping to a glyph in a font (that supports extra-BMP
> mappings);
> at present, FOP does not correctly handle this case in simple (non complex
> script) rendering paths;
> furthermore, though some support has been added to handle this in the complex
> script rendering path, it has not yet been tested, so is not necessarily
> working there either;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
