[
https://issues.apache.org/jira/browse/FOP-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357976#comment-15357976
]
Glenn Adams commented on FOP-1969:
----------------------------------
There are pros and cons to both approaches.
The biggest problem to changing signatures rather than adding new signatures is
that it will require a new major version update because it will be changing
public APIs or APIs that have been effectively treated as public even though
they might be argued to be internal. Doing this will cause more difficulty for
existing programmatic uses of FOP since it will require more changes than the
alternative.
However, the alternative, to add new signatures, means that users of existing
signatures will not benefit from the change, and may end up viewing these cases
as bugs. In such case, some code paths will function correctly with non-BMP
content but others will not, and determining which is which and addressing
those cases will create a long "tail" for this change, i.e., one that requires
many follow-on changes.
Having said that, I would probably take the conservative approach and do the
latter (add signatures) rather than the former (change signatures). That should
allow you to get some key code paths working sooner than others, but it will
create an obligation for further downstream work.
> 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: testing.fo, testing.fo, testing.pdf, testing.pdf,
> testing.xml, testing.xsl
>
>
> 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)
