PhilterPaper commented on Jul 12
Wed Jul 12 10:50:38 2017 futuramedium [...] yandex.ru - Correspondence added
Hi,
in my patch, both instances of "uc chr($uni)" can be replaced with "chr hex($ci->{upper})". They
should always be equivalent, I think. As to style/consistency/readability, at the time of writing, it seemed slightly better that way.
PhilterPaper commented on Oct 5
The Builder.pm changes seem to be unnecessary -- the missing $font was added a few releases ago, and
$opts{'-unicodemap'} is guaranteed to exist (default 1), so it's not necessary to check if it's defined.
As for the rest of the changes, I'll have to look at what Steve has in it already, and run the test case.
PhilterPaper commented on Oct 11
I have made some progress on this, and put it in GitHub, but I think there is still work to be done on synthetic fonts. The code appears to have only been tested with a TrueType font, as there is no encodeByName() method in core fonts or Type1 fonts. The call didn't seem to make any difference even for TrueType fonts, so I commented it out. If it turns out it's needed, something will have to be done for core and T1 fonts -- possibly just a dummy encodeByName() method. The author ("futuramedium") stated above that
uc and
->{'upper'} should behave the same, but in my testing,
uc didn't seem to handle non-ASCII characters (such as accented Latin letters). So, I reverted to the
upper code.
Other than that, the new code seems to work fairly well, so I am going to go ahead and commit it. There are still open issues that I want to look at some more, so I won't close this report yet.
- Restricted to single byte encodings.
- T1 and TT fonts gave some odd listings in 021_synfonts (some characters in wrong places), so I need to figure out what's going on, and whether it can be fixed or needs to be documented restrictions. Could this be the missing encodeByName()?
- automap() does not work for TT fonts, limiting 021_synfonts display to the basic 256 characters of an encoding.
- Some characters (especially ligatures), such as eszet (sharp s), 'n, fi, and fl; do not have upper case equivalents and "small caps" for them are unchanged. Currently this is documented as a caution to users, but consideration should be given (if there are not too many such cases) of automatically replacing these characters with multiple simple characters, so that they upper case properly. For example, replace a single eszet by two s's (lower case), so small caps shows SS, or an "fi" ligature by two letters f and i, so small caps shows FI.
- Consider extending 021_synfonts to gracefully handle T1 and TT fonts (currently only core).
PhilterPaper commented on Nov 3
I am going to close this issue, and offload a few items to #79 and #81.
1, 3 See #81 for further work in this area.
2 This appears to be limited to one PS (Type1) font (URW Palladio L), which may be a bad internal font encoding map supplied with the font. That's my assumption, anyway. I can't see anything that can be done about it on the PDF::Builder side. If more fonts show up with misplaced characters in the Synthetic Fonts (or elsewhere), this will have to be revisited.
4 See #79 for further discussion on this.
5 Done.