I'm finding your tone pretty aggressive, but will attempt to answer 
despite that...

Since Fonts vendors can build the codepages anyway they choose, we 
cannot simply build a static map that takes Unicode and maps to any 
custom codepage. Thus the user must specify non standard code points or 
build/acquire other fonts

This is a legacy of 1970s AFP technology.  There is a codepage titled 
T111200 in AFP land that can be acquired to meet the requirement of 
keeping the codepoints Unicode for AFP output. I've spoken to a couple 
of fonts vendors about building fonts for that code page. There are 
partial fonts in existence that do provide Glyphs for part of the 
Unicode range, but building a complete one is a mammoth task and they 
were quoting six figure $ sums to do so.

Unless the OP has such a font, then the solution using his current 
Characterset and Codepage is to use the codepoint x55

Thanks,

Chris

On 26/09/2017 20:50, Christopher R. Maden wrote:
> On 09/26/2017 11:08 AM, Chris Bowditch (JIRA) wrote:
>>
>>      [ 
>> https://issues.apache.org/jira/browse/FOP-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180912#comment-16180912
>>  
>> ]
>>
>> Chris Bowditch commented on FOP-2741:
>> -------------------------------------
>>
>> The solution is to insert code point x55 into the XSL-FO, e.g.
>
> (Taking the discussion out of JIRA...)
>
> I disagree with this pretty vigorously.
>
> The numeric character references in XML are *ALWAYS* to Unicode. 
> 3 is an exclamation point; U is a capital Latin U.  The fact 
> that AFP has a different encoding is a problem for the output system 
> to handle, not for the user to deal with.  Your proposed solution 
> would mean different input FO-XML for different outputs, which is 
> against the whole point of XSL.
>
> ~Chris


Reply via email to