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
