[Bugs][Fonts Unicode] problems with fonts
Locked
[Bugs][Fonts Unicode] problems with fonts
 
|
After trying out
the Unicode support (AllEncodings.pcl) and getting a bug which messes up fonts
and renders the system unusable, I investigated the problem a bit more closely.
The comments and analysis from Andrew NcNeil where right on, but there are
more problems. I hope this analysis will help others who are working with
fonts.
(BTW, this was the
first time I looked at the VM sources (ntfont.c on the perifery). This certainly
refreshed my appreciation for working in Smalltalk :-)
1. getting the
fonts from the OS and the system font on Windows
On startup all
screen fonts are requested from the OS with
HostGraphicsDevice>>listFontNames which uses a primitive (977 in
ntfonts.c). On windows the fonts are enumerated by 1) asking for all facesnames
and 2) asking for all fonts for each of the facenames. In the first step
many duplicate facenames are returned, but all duplicates appear in succession.
The VM eliminates them by comparing a facename with the last one returned and
discards it when equal. In this way the VM returns the fonts in the same order
as they are delivered from Windows. The first one seems to be always the System
font (a raster font with a fixed height). Nonetheless, the VM takes special care
that the system font is always the first returned by requesting it
separately.
The Unicode parcel
AllEncodings reimplements this with a different approach: eliminating duplicates
in the first step is done with a set which means that the order of the fonts
returned is basically random (depends on the ordering algorithm of Sets). It is
surprising that this is only a problem on few systems though (for me the
problem came with installing Adobe Illustrator with its
fonts).
2. default
font size
On all platforms
the default font size is fixed and hard coded except for Windows (why is that?).
There, the default font size is taken from the first font in the list. This why
the VM ensures that the system font is always first. The Unicode developers
obviously didnt know about that. Although this works (without Unicode), there is
a much more direct and reliable way to get the default size:
- select
the stock font SYSTEM_FONT into a HDC
- get the text
metrics
- read out the
height
3. raster
fonts
the VM adds a
variable sized font for each raster font family. I dont understand why this is
done, but a comment in the VM sources says "AR12384". Anyways, the Unicode
implementation doesnt do this. So whatever problem was solved with the
AR12384 workaround will reappear with the unicode
implementation.
Another problem is
that the stringified font description which is used between the VM and the image
does not encode the width of a font. Therefore, raster fonts with the same
height but different widths cannot be differentiated. Interestingly, some raster
font families cannot even get selected (see screen shot).
 4. encoding
names
the Unicode
implementation uses different names for encodings than the VM (f.ex. 'ms_cp_850'
instead of 'oem' and 'special<something>' instead of 'kanji'. I didnt
investigate the consequences, but I am sure that there will be
problems.
5. character
widths
in the VM I finally
found the reason why the width of strings on the screen never match the
string width on a printer (which makes layout of text for printing quite
difficult): the VM only returns rounded widths for characters! (at least for
Windows - I didnt check the other platforms). This is a bit arcane in the age of
scalable vector fonts...
6. ExtraEmphsis
breaks
with Unicode
loaded, ExtraEmphsis doesnt work properly anymore. It probably needs to be
reinitialized (which could be done by reacting to Locale
changes).
To summarize: fonts
in VW are quite a mess (which is well known to the community) and it gets
even worse with the Unicode parcels. Interestingly nobody from Cincom answered
to my first posting with an AR. So I assume that this has no priority
for future development of VW. Or am I wrong? What are the
plans?
cheers,
Christian
|
| Free forum by Nabble | Edit this page |