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.



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

Reply via email to