https://issues.apache.org/bugzilla/show_bug.cgi?id=48567
Jeremias Maerki <jerem...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #8 from Jeremias Maerki <jerem...@apache.org> 2010-01-21 09:48:08
UTC ---
I've applied your patches (documentation, too):
http://svn.apache.org/viewvc?rev=901793&view=rev
Thanks for the patch!
I've tested with referenced-fonts and that seems to do what I expect. The
MapCodedFont gets generated and should work if the font and the codepage are
installed on the target platform. Lacking a full AFP environment I cannot
easily test that to the very end. The only thing I noticed is that the viewers
don't recognize that the font is double-byte if the fonts are not embedded and
not available to the editor. I've added a TODO in MapCodedFont with an idea
which might help. In case you look into that class you may want to take a look.
As for the Unicode blocks we use to determine whether we have to use the em
space instead of a normal space for characters which don't provide individual
metrics, I think we don't have all that we need, yet. I've stumbled over
http://unicode.org/reports/tr11/ which mentions fullwidth and halfwidth
characters. However, I could not yet find the location where the information
for the destinction for each character can be found. With the font we tested
with we got away since the em space equals the normal space increment. For
fonts that have western characters, we may not get away with the current set of
Unicode Blocks. Not knowing enough about eastern languages is a real impediment
for me here.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
