Re: [Fonts]Re: Using TTF as a bitmap-only file format
Markus Kuhn [EMAIL PROTECTED] writes: Owen Taylor wrote on 2002-08-20 14:50 UTC: I'm afraid that a vast majority of programs and OS currently using TTF simple expect them to always have scalable glyphs; what will happen if one of such programs tries to use a bitmap only font for displaying at a size for xhich there are no bitmaps embedded ? I'm pretty sure Microsoft ships a number of .ttf files with only bitmaps and no outlines with Windows... Can you name a few examples to substantiate that claim? I believe I'm completely wrong about it :-) I got confused because FreeType handles .FON files, so if you point fontconfig at the fonts directory on your Windows partition, you get lots of bitmap-only fonts that you have to handle. But they aren't TTF files. The TrueType font format is certainly extraordinarily grotty. But it is also complete in ways that most other font formats aren't. (If we ever want to handle, say, bitmap Arabic fonts, then we really, really want to be doing it using OpenType GSUB tables rather than inventing new custom glyph encodings.) And widely standard. As Keith says, we can't *not* support TrueType. Regards, Owebn ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]TrueType fonts with Embedded bitmaps XF [was: FreeType bug report]
On Tuesday 20 August 2002 6:07 pm, Pablo Saratxaga wrote: | Kaixo! | | On Tue, Aug 20, 2002 at 05:44:13PM +0400, Vadim Plessky wrote: | | You should also decide on an extenson name other than .ttf, to avoid | | that those bitmap only ttf files get confused wwith real scalable | | fonts by people out there, otherwise there would be a lot of bad | | consequences. | | It seems to me that .ttf extension is o.k. for such fonts. | | I disagree. | Or have you tested with all programs that use TTF fonts directly, and | tested also in other operating systems (Windows, MacOS, BeOS,...) and | other graphical environments (like Berlin) that those fonts will work | and won't break anything ? I don't have Berlin installed, and do not own Mac, but I indeed tested fonts from http://jhcloos.com/fonts/bdfttf/tests/ (URL posted by James H. Cloos Jr. [EMAIL PROTECTED]) in Windows. 'ttfext' utility from MS correctly indetifies those fonts as TrueType fonts, and displayes all properties for them. And it says that font has embedded bidmaps. Unfortunately, I was not able to get sample page rendered for those font s- but I guess it's a Microsoft bug :-) On the other hand, ftview (from FT 2.1.1) correctly displays bitmap Courier and Helvetcia at 8pt, 10pt, 12pt and 18pt - for *TrueType* font. For OpenType - ftview displays nothing. And I guess here that it's either FreeType bug (ftview bug), or PfaEdit bug (which exported something incorrectly...) | | I'm afraid that a vast majority of programs and OS currently using TTF | simple expect them to always have scalable glyphs; what will happen | if one of such programs tries to use a bitmap only font for displaying | at a size for xhich there are no bitmaps embedded ? I think that we speak now about XFree86 running on Linux/FreeBSD. While it's nice to make fonts compatible with other OSes, I doubt that we can fix MS Windows or MacOS or Adobe bugs. | | But indeed Qt3/KDE3 and GNOME2/GTK2 should be patched/tested against | such fonts. | | There are a lot of utilities out there that use directly TTFs; from | little utilities creating images for web counters, to programs doing | 3D rendering of text,... and don't forget also other non-X11 environments; | very bad press will happen if fonts are disseminated that cause problems | (and they probably will be disseminated if people think they are just | normal TTF fonts). | | So, using a different extension name will solve a lot of trouble. If you think that people will take .ttf from XFree86 and install on Windows, and than complain that *your fonts do not work* - than I agree with you. ButI doubt that ordinar Windows user will install XFree86 fonts on its machine (Windoze). Usually opposite process happens :-) -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]FreeType bug report
On Tuesday 20 August 2002 9:57 pm, Juliusz Chroboczek wrote: | OT I'm pretty sure Microsoft ships a number of .ttf files with only | OT bitmaps and no outlines with Windows... | | Interesting. Which ones? GulimChe.ttf (Korean lang.font) has enermous amount of bitmaps, I think, for all point sizes up to 22pt. Original TTF is about 6MB in size, imported into PfaEdit it became .. 25MB in size! But GulimChe still has outlines (it's just small part of the font, though)... | | Juliusz | ___ | Fonts mailing list | [EMAIL PROTECTED] | http://XFree86.Org/mailman/listinfo/fonts -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Legacy software and bitmap-only snfts [was: FreeType bug report]
On Tuesday 20 August 2002 9:55 pm, Juliusz Chroboczek wrote: | PS You should also decide on an extenson name other than .ttf, | | I'm thinking of using .otf. The OpenType spec explicitly allows | bitmap-only OTF fonts. | | It should also be legal to generate .ttf fonts, under the condition | that I generate at least one entry in each of hmtx, glyf, and loca | (which I'm doing by default right now). See my another mail: Fonts made by James H. Cloos Jr. [EMAIL PROTECTED], URL: http://jhcloos.com/fonts/bdfttf/tests/ are displayed o.k. by ftview in TrueType format, but ftview dispalys nothing for .otf format. Tested with ftview/freetype 2.1.1 | | PS to avoid that those bitmap only ttf files get confused wwith real | PS scalable fonts by people out there, otherwise there would be a lot | PS of bad consequences. | | By default, I'm generating fonts which are perfectly valid TTF fonts. | To a non-sbit aware rasteriser, they will appear as fonts with only | one blank scalalble glyph. | | The good thing is that no existing software should crash on them. The | bad thing is that existing software will happily use them, which may | lead to user confusion. | | The alternative is to generate no loca or glyf tables at all, and | using the ``OTTO'' signature in the font's header. Existing software | should refuse to load such fonts, which will minimise user confusion. | | I'm waiting for the FreeType crowd to decide whether they wish to | support such fonts. | | Juliusz | ___ | Fonts mailing list | [EMAIL PROTECTED] | http://XFree86.Org/mailman/listinfo/fonts -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Is hinting worth the effort?
Another quick discussion related to font file format philosophy:
Is hinting really worth the effort?
Font file formats (even scalable ones) in principle ought to be
relatively simple creatures. The only aspect that really adds enormous
amounts of complexity, both with regard to the development of the
renderer as well as with regard to the creation of the fonts, is the
automated control point adjustment based on hinting information. Is that
type of scale-independent hinting really a good idea in the long run?
I'd like to argue that this is not necessarily the case, and would be
interested in hearing your more generic insights and opinions into the
subjects.
Main points:
- Even entry-level printing devices have now reached pixel sizes
of 20 µm or less, and many use in addition non-binary pixel
values for anti-aliasing, such that the changes of up to half a
pixel width to the outline when hinting is applied really does
not affect visible quality any more in printouts.
- For DTP applications, it is important that the on-screen
representation approximates as closely as possible the printed result
in a device-independent way, and hinting severely interferes
with that goal as it changes glyph spacings and sizes.
Experienced users know the problem that for example Microsoft Word
reformats a document if you change the resolution of the output device,
whereas Acroread uses unhinted glyph metrics in order to utilize
PDF as a truely device-independent format, which I find preferable.
- Neither web browsers nor GUIs have any need for exact freely
selectable glyph sizes. As long as a sufficiently smooth set of
glyph sizes with high-quality bitmaps is available, rounding to the
nearest font size that can be rendered in high quality is
perfectly acceptable (with say ~20% tolerance).
- The number of necessary bitmaps is relatively small. Glyphs less than
5 pixels high are unreadable anyway, with or without hinting, and
glyphs larger than around 50 pixels are sampled well enough such that
hinting starts to become unnecessary for a pleasant look, especially when
anti-aliasing is applied as well.
Therefore only for a single decade of glyph pixel sizes are manual
adjustments actually necessary. If the acceptable step size between
two font sizes is in the order of 20%, then manual adjustments are
necessary only for around 14-17 font sizes.
- Manually adjusting an unhinted glyph outline for a particular
low-res presentation can be done in one of two ways:
a) edit the resulting bi-level bitmap (switch some pixels
on or off to improve the looks)
b) manually snap control points to a nearby pixel boundary
Option a) is very easy to do and requires only readily available
bitmap software. I estimate that I can manually fix bitmap glyphs
at a rate of around 100 glyphs per hour. Option b) has the advantage
that it is compatible with anti-aliasing. I'm not sure how fast it
could be done; it would need a specialized software tool. The snapping
information can probabaly be compressed down to less than 4 bits
per control point and hinted scaling factor.
- I understand that the area of scale-independent hinting instructions
in font file formats has some patent problems. (?)
- In spite of the sophisticated hinting mechanisms available in
TrueType fonts, it seems that places like Microsoft Typography
do not make very significant use of it and embeds handedited
bitmaps instead.
So if we start one day some significant Free Outline Font project, shall
we really stick with existing TrueType/OpenType technology, or shouldn't
we skip the automatic hinting mess altogether and just add either
bitmaps or corrected control points for those scaling factors where,
let's say, the x-height is one of
$ perl -e 'for ($i=5; $i=50; $i=int($i*1.2+0.5)) {print $i, };'
5, 6, 7, 8, 10, 12, 14, 17, 20, 24, 29, 35, 42, 50
or
$ perl -e 'for ($i=4; $i=64; $i*=sqrt(sqrt(2))) {print (int($i+0.5) . , )};'
4, 5, 6, 7, 8, 10, 11, 13, 16, 19, 23, 27, 32, 38, 45, 54, 64,
The application would then specify to the renderer a font size and a
maximum tolerance (e.g., 20%), and if a hand hinted set of control
points is available within the tolerance, then the renderer will use
that that beautified on-screen font size instead of the exact requested
one.
(With regard to preferred numbers of font sizes, I believe that
neighboring fonts should be a factor 2^{1/4} = 1.1892 apart, because
this means for paper fonts that for example an A4-A3 magnification will
lead again to an exactly available font size. If you didn't understand
the last idea because you are North American, read then please have a
look at http://www.cl.cam.ac.uk/~mgk25/iso-paper.html.)
Just some food for thought ...
Markus
--
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at
[Fonts]Fonttootf: first cut of a BDF-TTF converter available
Hello, The first cut of fonttootf, a BDF to snft (TTF or OTF) converter for bitmap fonts is available from http://www.pps.jussieu.fr/~jch/software/files/fonttootf-20020821.tar.gz This is an early beta, please do not redistribute this version. A few caveats. First, you need a version of FreeType that contains the bug fix of August 19; this means current CVS. Second, due to another bug, you will not be able to use this code on BDF fonts (you'll need to convert to PCF first). Second, the Microsoft TrueType, Apple TrueType and OpenType specs differ on what tables are compulsory. Microsoft TrueType makes all tables compulsory. OpenType makes loca and glyf optional (but hmtx compulsory), while Apple TrueType makes all tables optional. Thus, fonttootf can generate different variants of fonts with the -m and -g flags. Please see the man page for details. In short, though, FreeType works with -g at least 2 and -m at least 1. Pfaedit requires -g 3. The cases -g 2 and -m 0 violate the OpenType spec; all other cases are legal. Here's a summary of font sizes: (1) (2) (3) .pcf.pcf.gz pfaedit fonttootf fonttotf -c 8x13-L1.pcf 19572 4579 6908 40124032 8x13.pcf41066057158 54044 52244 helvR14.pcf 7180413901 15780 15796 9x18.pcf + 18x18ja.pcf77976 + 580901 796464 917620 All sizes are in bytes. Column (1) is the size of the TTF generated by pfaedit; I didn't try to tune pfaedit's options -- this is not meant as a fair comparison, but rather as a baseline. Colum (2) is the size of the TTF generated by fonttootf by default; column (3) is the size of the TTF generated by fonttootf with glyph cropping disabled. The first font is a small (196 glyphs) small (8x13) charcell font. The second is a large (almost 4000 glyphs) small (8x13) charcell font. The third is a small (196 glyphs) small (14 ppem) variable width font. The fourth is a large large bi-width font generated from two charcell fonts (yep, fonttootf can do that). As you'll notice, cropping doesn't buy you much. In the case of the variable font, this is expected, as the font is already cropped (except that spaces are represented as 1x1 bitmaps, cropping eliminates the bitmaps altogether). In the case of the charcell and bi-width fonts, cropping does reduce the bitmap data quite a bit; however, the glyphs then have variable metrics, which prevents fonttootf from optimising the metrics table by encoding metrics only once. Thus, the gain in bitmap data is mostly offset by the larger metadata. Only in the case of the 18-pixel font, where the bitmap data dominates the font size, is cropping worthwile. Here's a selection of table sizes for the three TTFs generated from 8x13-L1.pcf. EBDT (bitmap data): (1) 2468, (2) 2272, (3) 2903. In case (2), we gain some w.r.t. pfaedit by writing metric-less bitmaps whenever possible. In case (3), the bitmap data is much larger, but all bitmaps are metric-less (as they are all equal) which makes the EBDT only slightly larger. EBLC (bitmap index): (1) 968 , (2) 698, (3) 84. As above. In case (2), some EBDT subtables have been replaced by metric-less tables. In case (3), there is a single metric-less table, and the EBLC is tiny. cmap (character to index mapping): (1) 698, (2) 52, (3) 52. Here we simply order all glyphs so that the cmap table is trivial. Pfaedit orders the glyph in what appears to be a random order, and therefore has to output a complex cmap. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Is hinting worth the effort?
I very much agree with Marcus, hinting is NOT worth the effort. Consider that hinting is really only absolutely necessary at font sizes less then 24 (excluding 5 which are going to be illegible no matter what). Embedding bitmaps is much easier. For my most recently released font ( http://www.dustismo.com/fonts/Dustismo.zip ) I spent about 5 weeks designing the glyphs, then I spent about a month trying to properly hint ONE character and I finally gave up and embedded bitmaps for sizes 7-22 which took about a month. It looks quit nice on my windows machine (it - of course - looks like crap on linux). The guy who did times new roman said he spent two years on the hinting alone, consider he could have embedded bitmaps for the same result and probably 1/30 the time. If anyone here has actually tried to properly hint a font I think they will agree that it is a most frustrating endeavor. Thanks Dustin cheapskatefonts.com At 05:52 PM 8/21/2002 +0100, you wrote: Another quick discussion related to font file format philosophy: Is hinting really worth the effort? Font file formats (even scalable ones) in principle ought to be relatively simple creatures. The only aspect that really adds enormous amounts of complexity, both with regard to the development of the renderer as well as with regard to the creation of the fonts, is the automated control point adjustment based on hinting information. Is that type of scale-independent hinting really a good idea in the long run? I'd like to argue that this is not necessarily the case, and would be interested in hearing your more generic insights and opinions into the subjects. Main points: - Even entry-level printing devices have now reached pixel sizes of 20 µm or less, and many use in addition non-binary pixel values for anti-aliasing, such that the changes of up to half a pixel width to the outline when hinting is applied really does not affect visible quality any more in printouts. - For DTP applications, it is important that the on-screen representation approximates as closely as possible the printed result in a device-independent way, and hinting severely interferes with that goal as it changes glyph spacings and sizes. Experienced users know the problem that for example Microsoft Word reformats a document if you change the resolution of the output device, whereas Acroread uses unhinted glyph metrics in order to utilize PDF as a truely device-independent format, which I find preferable. - Neither web browsers nor GUIs have any need for exact freely selectable glyph sizes. As long as a sufficiently smooth set of glyph sizes with high-quality bitmaps is available, rounding to the nearest font size that can be rendered in high quality is perfectly acceptable (with say ~20% tolerance). - The number of necessary bitmaps is relatively small. Glyphs less than 5 pixels high are unreadable anyway, with or without hinting, and glyphs larger than around 50 pixels are sampled well enough such that hinting starts to become unnecessary for a pleasant look, especially when anti-aliasing is applied as well. Therefore only for a single decade of glyph pixel sizes are manual adjustments actually necessary. If the acceptable step size between two font sizes is in the order of 20%, then manual adjustments are necessary only for around 14-17 font sizes. - Manually adjusting an unhinted glyph outline for a particular low-res presentation can be done in one of two ways: a) edit the resulting bi-level bitmap (switch some pixels on or off to improve the looks) b) manually snap control points to a nearby pixel boundary Option a) is very easy to do and requires only readily available bitmap software. I estimate that I can manually fix bitmap glyphs at a rate of around 100 glyphs per hour. Option b) has the advantage that it is compatible with anti-aliasing. I'm not sure how fast it could be done; it would need a specialized software tool. The snapping information can probabaly be compressed down to less than 4 bits per control point and hinted scaling factor. - I understand that the area of scale-independent hinting instructions in font file formats has some patent problems. (?) - In spite of the sophisticated hinting mechanisms available in TrueType fonts, it seems that places like Microsoft Typography do not make very significant use of it and embeds handedited bitmaps instead. So if we start one day some significant Free Outline Font project, shall we really stick with existing TrueType/OpenType technology, or shouldn't we skip the automatic hinting mess altogether and just add either bitmaps or corrected control points for those scaling factors where, let's say, the x-height is one of $ perl -e 'for ($i=5; $i=50;
Re: [Fonts]Is hinting worth the effort?
Around 17 o'clock on Aug 21, Markus Kuhn wrote: Is hinting really worth the effort? If you separate hinting into the two pieces supported by TrueType (instructions and deltas), then I would agree that the instruction portion is irrelevant. Good TrueType output is almost always generated by delta hints which are size-specific. - For DTP applications, it is important that the on-screen representation approximates as closely as possible the printed result in a device-independent way, and hinting severely interferes with that goal as it changes glyph spacings and sizes. When reading or editing a document on screen, the glyphs should be hinted to make the letters sharp and easy to read. How applications adjust to the differences between screen and printer metrics is a separate issue. The Windows problem is exacerbated by the lack of printer metrics through the GDI interface. Using FreeType, applications would have access to the underlying glyph sizes and be able to adjust the display to make it more closely approximate what would appear should the document be presented at higher resolution. a) edit the resulting bi-level bitmap (switch some pixels on or off to improve the looks) Obviously uninteresting as it eliminates anti-aliasing and sub-pixel rendering. b) manually snap control points to a nearby pixel boundary Unless you're careful, this is covered by the TrueType delta-hint patent which covers any relative motion of control points(!) for the purpose of adjusting glyph shapes on the display. TrueType uses the combination of size-independent instructions and delta-hints to reduce the total size of the font; delta hints are only needed for important glyphs where the instructions don't get the right results. - I understand that the area of scale-independent hinting instructions in font file formats has some patent problems. (?) One of the techniques used in the instructed hinting is patented. This involves the separation of the basis of measurement from the basis for adjustment. One obvious application of this is in hinting diagonal stems -- the hint measures the width of the diagonal element while adjusting the control points along a horizontal line to keep the corners of the glyph at the same elevation. - In spite of the sophisticated hinting mechanisms available in TrueType fonts, it seems that places like Microsoft Typography do not make very significant use of it and embeds handedited bitmaps instead. Very few western TrueType fonts include bitmaps; they rely instead on delta hints. Embedded bitmaps are relegated to Han fonts and are provided at only a very few sizes. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Using TTF as a bitmap-only file format
MK How alone am I with my scepticism of TTF here, especially with the idea MK of streching its intended application field to pure pixel fonts? Markus, As you may imagine, I did spend quite a bit of time thinking about this issue before setting out to write fonttootf. I am now convinced that encoding bitmap fonts in an snft wrapper is a good idea. The snft font format is, as you justly note, incredibly baroque. Implementing anything related snft requires reading three specifications in parallel, working out which features are obsolete, which are deprecated, and which are supported on your own. A lot of data are encoded multiple times (for example, in head for Apple platforms, in OS/2 for Microsoft platforms, in post, in PCLT). (My favourite example is the handling of the (3,0) Microsoft Symbol cmap -- have a look at ftenc.c and cry.) On the other hand, the snft format is reasonably well understood by now; the number of snft experts I can reach with a single well- directed e-mail compensates for a lot. Additionally, some parts of the format are very carefully designed. The format is intrinsically seekable, which saves quite a bit of memory for large fonts -- important now that, thanks to your work, most of our fonts contain thousands of glyphs. It is also extensible, and there are reasonably well-defined ways of encoding anti-aliased bitmaps as well as complex script information in the format (OpenType Layout -- another morass of complexity, though). Finally, my experiments show that the sfnt format, based on years of Apple's experience with 128 KB machines, does allow encoding of bitmaps in a particularly compact manner; your 8x13 is smaller in sfnt than in gzipped PCF! I do fully intend to push the experiment further, and adapt both mkfontscale and the FreeType backend to use this sort of fonts. I do not feel the need to push the format, as I have no doubt that once the format is fully supported, our users will naturally move towards using sbit-only TTFs for its bitmap fonts. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
