I'm finding your tone pretty aggressive, but will attempt to answer
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
On 26/09/2017 20:50, Christopher R. Maden wrote:
> On 09/26/2017 11:08 AM, Chris Bowditch (JIRA) wrote:
>> 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.