I understand the point you are making. This is open source so patches that improve the status quo are welcome. :-) But as I already mentioned I don't know of a practical way to meet the requirement.
Thanks, Chris On 27/09/2017 17:45, Christopher R. Maden wrote: > On 09/27/2017 09:44 AM, Chris wrote: >> 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 > > I apologize if my tone came across wrong. > > However, as Glenn notes, XML numeric references are unambiguous; > 3 is always an exclamation point. > > For an analogous example, the advice to generate a capital delta used > to be to type a D but assign the Symbol font; now we know better, and > can actually type Δ, and be unambiguous about what we mean. > > I appreciate that AFP is antique and mapping is difficult. But the > mapping belongs somewhere outside the input FO-XML; if someone knows > that a particular font needs to map 0x33 to 0x55, then a mapping file > will not only keep that information separate from the input, it will > also make it easier to share among users of that font. > > Respectfully, > Chris