[ 
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)

Reply via email to