Re: [Fonts] fontconfig segv

[James H. Cloos Jr.]

Hmmm.  I just tried eliminating parts of my fonts.conf to see whether
that made any difference.  And it did.  If I removed:



unknown

rgb


things work a bit better.

Oddly enough, though, the fonts are still AAed as rgba

Also, gucharmap will still segv when looking at certain parts of
unicode.  It must be looking for a font to match a certain range and
triggers the segv by doing so.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts] fontconfig segv

[James H. Cloos Jr.]

I just tested out gucharmap in a gentoo chroot.  It has xfree86 4.3.0,
fontconfig 2.1, pango 1.2.1; generally the latest releases of everything.

Gucharmap however is giving a segv in FcConfigAdd():

#0  0x42d1d75d in FcConfigAdd (head=0x4, position=0x0, append=1, new=0x8127de0) at 
fccfg.c:925
#1  0x42d1cb55 in FcConfigSubstituteWithPat (config=0x80a36c8, p=0x8128ea0, 
p_pat=0x81309e8, 
kind=FcMatchFont) at fccfg.c:1160
#2  0x42d24bea in FcFontRenderPrepare (config=0x1, pat=0x81309e8, font=0x80a5a40) at 
fcmatch.c:439
#3  0x42d24ebd in FcFontSetMatch (config=0x80a36c8, sets=0xbfffbdb8, nsets=1, 
p=0x81309e8, result=0xbfffbe08)
at fcmatch.c:520
#4  0x42d2509b in FcFontMatch (config=0x0, p=0x1, result=0x1) at fcmatch.c:542
#5  0x42fb976f in pango_fc_face_describe () from /usr/lib/libpangoxft-1.0.so.0
#6  0x42f87b75 in pango_font_face_describe () from /usr/lib/libpango-1.0.so.0
#7  0x400f616f in style_changed () from /usr/local/gucharmap/lib/libgucharmap.so.1


The segv happens at for for loop below:

static FcBool
FcConfigAdd (FcValueList**head,
 FcValueList*position,
 FcBool append,
 FcValueList*new)
{
FcValueList**prev, *last;

if (append)
{
if (position)
prev = &position->next;
else
for (prev = head; *prev; prev = &(*prev)->next)
;
}

The problem is that head cannot be dereferenced even once, much less
twice.

Given that I cannot convince the program to dump a core, nor do I see
anyway of getting gdb to do so, does anyone have any suggenstions on
tracking down the bug here?

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts] filtered Tempest fonts

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

MK> Putting an anti-tempest filter into freetype2 has been on my todo
MK> list for a long time

Juliusz> Could you guys be so kind as to tell us mere mortals what
Juliusz> you're speaking about?

Presumably the idea is to manipulate the glyphs in such a way that,
while the visual display is not impaired, the recovery of that data
from monitoring the monitor's EM emmissions is impaired.

Essentially a steg technique, yes?

Sounds fun.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Re: X-TT and OTF

[James H. Cloos Jr.]

> "Mike" == Mike FABIAN <[EMAIL PROTECTED]> writes:

>> You should not modify X-TT to read .otf font files, as that would
>> prevent freetype from getting at OTF/CFF fonts if X-TT is loaded.

Mike> Why would it prevent freetype from getting at OTF/CFF fonts?

The backends for server-side fonts match files in the font path
against filename patterns to determine whether to service or ignore.
Were the x-tt backend to claim files matching the glob *.otf the ft2
backend might not be given the opportunity to do so.  (Each backend
is tried in turn until one chooses to handle the file.)

The font info I cut out above looks like a ttf/otf rather than a
cff/otf, so a .ttf filename extension is probably more reasonable.
Such a name change does match the conventions used by adobe/apple/ms.

(I'd rather see the servers use file magic rather than file names
to split up font handling responsibilities between the font backends,
but obviously not badly enough to write and submit such code to the
xfree86 team  That probably puts me in good company.)

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Dealing with standard bitmap fonts in Xft

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> If it is, then I'd like to move the priority for FC_OUTLINE in the
Keith> match order above FC_FAMILY.  Then I can add a match/edit rule
Keith> that sets outline to true and outline fonts will be preferred
Keith> even when the requested family is available in bitmap form.

That does sound like the way to go.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]ft2 server-side backend

[James H. Cloos Jr.]

looks like the new backend was comitted yesterday

cool

-jimc

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Thyromanes fonts not working with xft2

[James H. Cloos Jr.]

> "Yong" == Yong Li <[EMAIL PROTECTED]> writes:

JimC> Part of the problem may be that they only have mac roman charmaps:

Yong> Actually they have 3 charmaps. The other two (one of them is
Yong> Microsoft Unicode) are buggy and got rejected by the validation
Yong> tests in FT 2.1.x (up to 2.1.2 at least).

I forgot about that; I should have thought of it and looked further
than just ftdump's output

-JimC


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Thyromanes fonts not working with xft2

[James H. Cloos Jr.]

Around 1 o'clock on Sep 30, David Starner wrote:

> (Package ttf-thryomanes.) Unfortunately, they
> don't seem to display correctly in XFT2 programs

Part of the problem may be that they only have mac roman charmaps:

:; ftdump thryn___.ttf 
There is 1 face in this file.

- Face number: 0 -

font name entries
   family: Thryomanes
   style:  Regular
   postscript: Thryomanes

font type entries
   FreeType driver: truetype
   sfnt wrapped:yes
   type:scalable
   direction:   horizontal
   fixed width: no
   glyph names: yes
   EM size: 2048
   global BBox: (-1117,-654):(2734,2114)
   ascent:  1741
   descent: -481
   text height: 2555

charmaps
   0: platform: 1, encoding: 0

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Much worse rendering with latest fontconfig package

[James H. Cloos Jr.]

> "Jeffrey" == Jeffrey Baker <[EMAIL PROTECTED]> writes:

Jeffrey> It is indeed the same version and build of freetype used in
Jeffrey> both of my previous examples.

In the png you posted, if they are the same font, the diference is
definitely hinting.  There are options in ft to control whether
hinting is used, and if so whether to use the byte code or ft's own
autohinting algorithm.  

I don't see anything in the Xft1 src (either version) that references
those flags, and am getting instructed glyphs.  (I can read them as
small as 3 pt at 133 dpi.)

Did you use lsof to confirm that the app was using the same version of
ft and the same font file under both examples?  I, eg, ended up
getting a different font for 'mono' from my font.conf config than I
was getting from my XftConfig config.  lsof will show exactly what
font file is being used, as will /proc/$pid/maps.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]blank glyph list in fonts.config

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> 0x1680 

AIUI, and I do not read Ogham, U+1680 is only blank in some fonts, and
is a horizontal line in others.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Fontconfig release - fcpackage version 2.0

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

>> Perhaps also /usr/X11R6/lib/Acrobat5/Resource/Font and

Keith> I've never seen a system with fonts in that directory, is it
Keith> specific to some commercial product?

Well, some closed-src free as in beer product available for ftp
anyway.  It does provide access to a certain set of four rather nice
cjk otf fonts, but I can see where it may be better off in local.conf.

>> /usr/share/texmf/fonts/type1 are good ideas.

Keith> That one is probably *not* a good idea -- the TeX fonts all
Keith> have the same name making them pretty useless in non-TeX
Keith> environments.

The FontNames do of course have to be unique.  And zilla's mathml
support will need access to math fonts.  Do the fc patches for zilla
allow it to work w/ only client side fonts?  Ie, can one configure it
to never look for server side fonts?  (Certain web pages cause my X
process to blow up to over half a gig; tonight's project is to compile
1.1 w/ the fc patch, plus whatever else I need to add to get it to
ignore the server fonts (except perhaps for the widgets).)

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Fontconfig release - fcpackage version 2.0

[James H. Cloos Jr.]

I thought I sent this before, but perhaps not.

I'd add /usr/local/share/fonts to the default fonts.conf.

Perhaps also /usr/X11R6/lib/Acrobat5/Resource/Font and
/usr/share/texmf/fonts/type1 are good ideas.

-JimC


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]edit antialias=false equivalent in fonts.conf

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> I'd say that the question of whether you want to use the
Keith> embedded bitmaps is essentially the same as to whether you want
Keith> to use anti-aliasing.  Well hinted Western fonts are
Keith> essentially equivalent to embedded bitmaps.

On a related note, it may be worthwhile to offer the option of aa-ing
bitmaps (embedded or otherwise).  AA improves even the best-instructed
ttfs even though only curves and diagonals are changed.  Bitmaps can
benefit from that just as much as well-instructed ttfs.

How much work would it take to support that?

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]enquiry about pcf/bdf font support

[James H. Cloos Jr.]

> "Vadim" == Vadim Plessky <[EMAIL PROTECTED]> writes:

Vadim> Do you have URL with fonts *ready*?

It looks like my post with the url failed to make it to the list

The 100dpi and 75dpi dirs of fonts are at:

http://jhcloos.com/fonts/bdfttf/tests/

The tar files have the bdfs and each of the four variations of ttf/otf
pfaedit will produce from them.

The pfaedit scripts included in those tars will only work as written
with a very recent version of pfaedit; I beleive the relevant bug fix
was committed on Aug 15.  If you have an older version, you'll need to
make the pathnames in the Import commands absolute.

-JimC



___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]enquiry about pcf/bdf font support

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

Juliusz> I'm still not getting anything close to what you claim:

I'll be posting the pfaedit generated ttfs later tonight.  George
fixed a bug that was making it more difficult than necessary to
generate the scripts to automate conversion -- and did so w/in just a
few hours of when I posted the report; gotta love free/open software.

JC> Is there any benefit to a bdat table over a EPDT table?  pfaedit
JC> also shows sbit as an option,

Juliusz> The TTF spec doesn't document either.  I'll have a look in
Juliusz> the OTF spec and the GX documentation (if I can still find it).

I beleive apple still has it all online; I was very recently pointed
to some of that doc from a post on, I suspect, the opentype list.

Juliusz> Do you know what is implemented by FreeType 2?

ftview has no problem with EPDT+EBLC or bdat+bloc type ttf files as
generated by pfaedit, but does not see the bitmaps in either format
otf files as generated by pfaedit.  The only difference is a glyf
table with entries that look like this when ttdumped to ttx:



vs a CFF table with entries that look like this in ttx:


  -190 endchar


(Note that not all have negative args to endchar) and that the CFF
versions do not have cvt or loca tables.  It is probably the lack of
one of those two tables that keeps ftview from displaying the bitmaps
in the otf versions.

Expect a URL for the four variations of at least most of the bdf fonts
in xfree86's cvs w/in the next twelve hours.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]enquiry about pcf/bdf font support

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

JC> The resulting ttf worked fine.

Juliusz> Could you tell me whether the hmtx contains a full set of
Juliusz> metrics, or only metrics for .notdef?

All of the glyphs where listed in the _h_m_t_x.ttx file generated by
Just's ttdump, with name, width and lsb attribs to the mtx tags.  All
of the lsb attribs were 0 in the fonts I've dumped, except for .notdef
(which pfaedit adds to all ttfs it generates).

JC> OTOH, the pfaedit-generated ttf (or otf) was about 1/6 larger than
JC> the total of the gzip(1)ed pcf files per wc -c, but only 8k larger
JC> per du.

Juliusz> I'm getting slightly worse results here:

1/6th larger was for the comparison of all of the utopia strikes in a
single EBDT style font vs the ten 10646-1 pcf.gz files.

Juliusz> On the other hand, this will get smaller when I implement (1)
Juliusz> glyph sharing, ... (2) composites detection, (3) segments
Juliusz> with uniform metrics and (4) bit-padded (as opposed to
Juliusz> byte-padded) bitmaps.

Is there any benefit to a bdat table over a EPDT table?  pfaedit also
shows sbit as an option, but I've not been able to get it to generate
a usable font with that option.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]enquiry about pcf/bdf font support

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

Juliusz> I think he meant combining multiple sizes into a single TTF.
Juliusz> Recall that TTF/OTF is a scalable format, and may contain
Juliusz> sbits for multiple sizes (``strokes'' in OTF parlance).

I did run the two distinct points together.  Multiple sizes into a
ttf/otf should I think definitely be done.  Whether those ttf/otf
files should then be combined by family into a ttc/otc is a separate
issue.  I strongly advocate the former, whereas the latter is just
something I thought of while keying in the reply


I just tried importing each of the utopia bdfs into pfaedit and
generating a ttf.  The 18pt and 24pt 75dpi bdfs could not be imported
w/o overwriting 100dpi versions because they had the same PIXEL_SIZE.
I think this is a limitation of pfaedit rather than the ttf/otf format.  

The resulting ttf worked fine.  It did include a .notdef outline
(instructed, even) in the glyf table, as well as empty entries for
each of the other glyphs.  So the existance of a .notdef outline
should probably be actively ignored when determining whether the font
is bitmap-only.  I'm sure other (general purpose) ttf generators will
also do that.

.notdef did not get an outline in the CFF table, however, when I
generated on otf file, but none of the several versions I have of
ftview would show the bitmaps in the otf

OTOH, the pfaedit-generated ttf (or otf) was about 1/6 larger than the
total of the gzip(1)ed pcf files per wc -c, but only 8k larger per du.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]enquiry about pcf/bdf font support

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> I've since had a revelation that we should discard PCF font
Keith> files and replace them with TTF files containing an embedded
Keith> bitmap.

Cool.  I've also been thinking this for some time now.

I'd like to see this designed to combine all of the dpi-pt_size
variations of a given face into a single ttf.  (It may even be
a good idea to also collect the WIEGHT, SLANT, SETWIDTH and
ADD_STYLE variations into a ttc; this should be discussed.)

The resultant ttfs should also, IMO, include sufficient hints so that
mkfontdir can generate fonts.dir entries from them exactly as it now
can from the bdf files.  In fact, all of the properties from the bdf
files' STARTPROPERTIES section should be encoded into the ttf.  

Exactly how the properties should be encoded is another topic in need
of discussion.  A new table could be added (perhaps named something
like XF86, XFLD, XBDF or BDFP) to encode all of the props with
pointers to which bitmap they refer.  Or perhaps the current tables
are sufficient to encode all of that data.

Keith> If anyone has experience writing TrueType font files, help
Keith> would be greatly appreciated in building something that can
Keith> create these new files.

It might be easier to start by writing a bdf2ttx util and using Just's
fonttools package to compile to ttf.  Or perhaps just extend fonttools
to read in a (set of) bdf(s) and dump out a ttf.

Alternatively, pfaedit ought to be able to do this right now, and
could be scripted to automate the task.

Either package would be good code to test against.

P.S.  As a related sidenote, has anyone tried writing an xfs
  on top of fontconfig/xft2/ft2?

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Sharing fonts between X server and Xft

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

Juliusz> If you decide that's the way to go, I'll be glad to cook a
Juliusz> standalone and GPL-free bdftootf utility and implement
Juliusz> support in the core fonts system.

It's always cool when something I've been contemplating is the same
conclusion those who've been studying the problem even longer come up
with.  :)

An XF86 (or perhaps Xorg) table containing the info required for the
XLFD is also a good idea.  It should also be used in any scalable
fonts it may be found in.  

Hmm.  Maybe XLFD is the best name for the table?

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]FreeType 2 backend submitted for inclusion in CVS

[James H. Cloos Jr.]

> "Mike" == Mike A Harris <[EMAIL PROTECTED]> writes:

Mike> I'm considering the possiblity of including all or some of this
Mike> in my XFree86 packaging in rawhide.

I suggest you do so.

Mike> How well do you think it would fit into 4.2.0?

I'm using it right now on a suse 7.3 box with their rpm modified to
patch in Juliusz' backend.  It works very well.

The only note is that if the current version had not added CID
support, I'd suggest patching the type1 backend like so:

diff -uNrdb Type1.bak/t1funcs.c Type1/t1funcs.c
--- Type1.bak/t1funcs.c Mon Feb 18 15:51:57 2002
+++ Type1/t1funcs.c Tue Jun 18 18:44:26 2002
@@ -1443,10 +1443,6 @@
 #else
 static FontRendererRec renderers[] = {
 #endif
-  { ".pfa", 4, NULL, Type1OpenScalable,
-NULL, Type1GetInfoScalable, 0, CAPABILITIES },
-  { ".pfb", 4, NULL, Type1OpenScalable,
-NULL, Type1GetInfoScalable, 0, CAPABILITIES }
 };
 
 #ifdef BUILDCID
@@ -1464,17 +1460,7 @@
 void
 Type1RegisterFontFileFunctions(void)
 {
-int i;
- 
-#ifdef BUILDCID
-Type1InitStdProps();
-for (i=0; i < sizeof(Type1RendererInfo) / sizeof(FontRendererRec); i++)
-FontFileRegisterRenderer(&Type1RendererInfo[i]);
-#else
-T1InitStdProps();
-for (i=0; i < sizeof(renderers) / sizeof(FontRendererRec); i++)
-FontFileRegisterRenderer(&renderers[i]);
-#endif
+ /* null function */
 }
 
 int 


That will ensure that the old type1 backend only serves the cid
fonts.  If the ft2 backend does now include cid support, the patch
would need to exclude the old type1 backend from libfont.{a,so}.

Also, this patch may be a reasonable addition to the ft2 backend:

diff -udNrb xc.old/lib/font/FreeType/ftfuncs.c xc.new/lib/font/FreeType/ftfuncs.c
--- xc.old/lib/font/FreeType/ftfuncs.c  Tue Apr 16 22:25:38 2002
+++ xc.new/lib/font/FreeType/ftfuncs.c  Tue Jun 18 18:49:31 2002
@@ -1739,6 +1739,10 @@
  FreeTypeGetInfoScalable, 0, CAPABILITIES},
 {".PFB", 4, 0, FreeTypeOpenScalable, 0,
  FreeTypeGetInfoScalable, 0, CAPABILITIES},
+{".pfr", 4, 0, FreeTypeOpenScalable, 0,
+ FreeTypeGetInfoScalable, 0, CAPABILITIES},
+{".PFR", 4, 0, FreeTypeOpenScalable, 0,
+ FreeTypeGetInfoScalable, 0, CAPABILITIES},
 };
 static int num_renderers = sizeof(renderers) / sizeof(renderers[0]);
 
given that ft2 now supports pfr0 fonts.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]ft2 backend pixelsize vs bitmap pixelsize

[James H. Cloos Jr.]

I just replied to the xpert thread about a scalable version of fixed
with a quick not on scaling arbitrary scalable fixed-width fonts to
match a given XLFD.

In doing so, I discovered that fixed, aka:

-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1

has an ASCENT of 11 and DESCENT of 2 (totalling 13), whereas

-b&h-Luxi Mono-medium-r-normal--[9.75 0 0 13]-0-75-75-m-0-iso8859-1

while intended to match those metrics ends up with an ASCENT of 13 and
DESCENT of 3.

IOW, the pixels size of the bitmap fonts matches the sum of ascent and
descent but the pixel size of fonts rendered with the version of the
ft2 backend I have installed instead matches just the ascent.

Because of a quirk in how libfont gets compiled, the type1 render is
used by the font server for .pfa and .pfb, so I can compare the two
backends for type1 fonts.  The type1 backend also uses the specified
pixelsize for ascent rather than the sum of ascent+descent.

Perhaps the bdf fonts are mis-named?  Or is this an expected differece
between monospace and charbox fonts?

As a side note, the type1 backend includes RAW_PIXEL_SIZE in addition
to RAW_POINT_SIZE in xlsfonts -ll output.  That might be useful for
the ft2 backend to support.  (It is of course 1000 for typical t1
fonts and probably 2048 for typical ttf fonts.)

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts][OpenType] Hinting question

[James H. Cloos Jr.]

The attached message was sent to the opentype list.

It implies that ttf (glyf) fonts can be the logical equivalent of
optical axis multiple master fonts given that point size, device
resolution and font transform are separate args to the bci.  As such,
if the point size arg is used to carry the design size and the
transform is used to modify that into the user's request size, the
logical equivalent of optical scaling should result.

Provided that the font designer and the rasterization engine coöperate.

Are there any implementation details in freetype of xft{1,2} that
would prevent this from working?

-JimC

(As you might guess, I'm a big fan of optically scaled fonts.)


--- Begin Message ---

(If there is a better forum in which to post this question, please let me
know.)

My understanding is that TrueType hinting takes the point size, device
resolution, and font transform as separate components.  The point size
indicates the optical size of the font, and is used to customize the
outline of the glyphs for the intended optical size (control serifs, stem
thickness).  The device resolution and transform are used to control
rasterization, to avoid unequal stem widths and so on.

In practice, do type designers, and rasterizers, make use of these
distinctions?  Or do type designers seldom perform optical size
adjustments, and rasterizers generally roll the data into one transform
matrix?  If so, then it is not possible to distinguish the point size from
the 'zoom factor', or to identify the actual intended physical size of the
font.  Is this a problem?

--- End Message ---

Re: [Fonts]Re: Adobe Glyph Names <-> Unicode 3.2 (was: Xft and MathML)

[James H. Cloos Jr.]

> "Markus" == Markus Kuhn <[EMAIL PROTECTED]> writes:

Markus> It might be very worthwile to start updating the PostScript
Markus> glyph names in the various TeX Type1 fonts to match current
Markus> standards, as soon as Adobe has updated

Markus>   http://partners.adobe.com/asn/developer/type/unicodegn.html

Markus> to Unicode 3.2 coverage.

Markus> Who is currently on charge of these font files? AMS?

comp.text.tex is probably still the best place to discuss that.
Perhaps also [EMAIL PROTECTED]  I've included both on
the CC here.

THe cm-super t1 fonts already do follow unicodegn.html, but the math
mode fonts are not included.  (Verified by looking at the FullName
fields of the afm files.)

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]Re: Adobe Glyph Names <-> Unicode 3.2 (was: Xft and MathML)

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> Of the 231 unique glyph names in the blue sky math fonts, 66
Keith> are not represented in glyphnames.txt. ...

Keith> fontconfig already unifies multiple encoding tables into a
Keith> single unicode mapping function ...

Another issue is whether eg Computer Modern Math Italic glyph /x
should map to U+0078 LATIN SMALL LETTER X or to U+1D465 MATHEMATICAL
ITALIC SMALL X.  

The latter would help indicate that its metrics are designed for
setting math rather than text, but unicode does AIUI recommend
encoding that info at a higher level

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Re: Adobe Glyph Names <-> Unicode 3.2 (was: Xft and MathML)

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> I'm more interested in discovering whether the existing fonts
Keith> used for MathML include these [adobe recomended] glyph names so

Probably not.  The (postscript versions of the) interesting math fonts
I beleive all predate adobe's glyph naming recomendations.  (At least
for the TeX-related ones; I cannot speak definitively on mozilla's
other set of recomended math fonts (by bitstream for corel, yes?).)

If you have a full tetex install, check out eg:

/usr/share/texmf/fonts/type1/bluesky/cm/cmmi10.pfb
/usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb

with t1disasm to get the glyph names.  Another interesting example are
the lucida math fonts.  The afms are included in tetex in:

/usr/share/texmf/fonts/afm/yandy/lumath/

None of the glyphs in these fonts which are in unicode but not in
adobe's glyphlist.txt follow the uni or uXX name format.
Even some of the glyphs which are in glyphlist.txt may not have the
same name as adobe recommends.

For the (type1) math fonts you will need font-specific glyphname to
unicode codepoint tables.  Even the ttf versions of these fonts will
probably need such a table.  It would presumably be useful were these
tables in text files a la the enc files used by X for server-side
fonts or by TeX-related utilities such as dvips, et al.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]fontconfig: multiple fonts w/ same name ?

[James H. Cloos Jr.]

Given a setup with both truetype and type1 versions of a given set of
fonts (as is seen w/ most installs w/ the Luxi fonts, and may show up
with CM fonts), there should be a way via fonts.conf to prefer one or
the other format.

Not all such fonts have the same name.  The ttf versions of lucida
fonts shipped with sun's java runtimes/sdks show up with different
names via fontconfig than the (mostly¹) equivalent type1 fonts.  I
understand adobe altered the names of the type1 libarary when they
released them as otf.  But I'm sure Luxi and CM are not the only 2
examples in the wild where the t1 /FullName and the ttf name table
have identical strings.

Another similar issue is different versions of the same font.
It would be useful to order the fonts by version in the case
of name collisions.  As it is I don't see any way the users
could determine which version -- ie which file on disk --
would be used for a given font specification w/o actually
trying it out.

-JimC

¹ The ttf version have a *much* larger glyph repertoire than
  the type 1 versions I purchased from yandy.com; the latter
  may have been expanded since, but I doubt it.

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Releasing Xft2 and Fontconfig

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> Well, it doesn't crash for me.  But, my version of FreeType
Keith> (2.0.9) doesn't seem to find any non-BMP encodings in the
Keith> type-4 table, it finds 30 type 4 segments in code2001.ttf, the
Keith> last of which encodes glyph 65535.

I've got freetype at 2.1.0; perhaps this tweaked one of the cmap bugs
there.  I'll give it a try with VER-2-1-1-RC1 a/o HEAD branches; if
2.1.0 is at fault here (at least one of) those ought to work OK.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Releasing Xft2 and Fontconfig

[James H. Cloos Jr.]

Hmm.  Looks like I forgot to send this on the other day

Fontconfig-1.0.1's fc-cache dies when it hits a directory containing
code2001.ttf.  I presume it is due to the non-bmp characters in the
font.  ftview displays the font.  pfaedit says:

:; pfaedit -nosplash code2001.ttf 
Copyright © 2000-2002 by George Williams.
 Executable based on sources from 13:56 16-4-2002.
Invalid ttf vmtx table (or vhea), numOfLongVerMetrics is 0

and fonttools' ttdump dies in the maxp table, even when given
an -x maxp arg.

So perhaps the font is buggy.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Georgian unicode

[James H. Cloos Jr.]

> "Aidan" == Aidan Kehoe <[EMAIL PROTECTED]> writes:

Aidan> To get your Georgian support fonts shipping, you can either
Aidan> base them on a font with a less restrictive licence, and supply
Aidan> them to XFree86 with that licence, or give them to URW, who
Aidan> should help with their distribution under the GPL.

Rather than involving URW, I'd suggest getting in touch with the
freefont project at the FSF.  Cf:

   http://www.freesoftware.fsf.org/freefont/

and

   http://savannah.gnu.org/projects/freefont/

for more info on that project.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New versions of mkfontscale and FreeType 2 backend

[James H. Cloos Jr.]

JC> I just realized that there is a significant difference with the new
JC> ft2 backend.  I've lost underlining in mozilla.

Juliusz> Please check the values of the UNDERLINE_POSITION and
Juliusz> UNDERLINE_WIDTH properties (xlsfonts -ll -fn 'foo').

With Georgia, UNDERLINE_POSITION is O(-PIXEL_SIZE/10) and thickness
is O(PIXEL_SIZE/20).  Other ttf and otf fonts seem to be the same.

With type1 fonts, the UNDERLINE_POSITION is O(PIXEL_SIZE/10).  I
presume the sign is then the problem. ... ...  Yup.  The underlines
reappear when I choose a type1 font.  I thought I tested that, but
obviously I didn't do so thoroughly. :(

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New versions of mkfontscale and FreeType 2 backend

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

JC> I'm also having trouble adding /usr/lib/jdk1.3/jre/lib/fonts to
JC> the font path.

Juliusz> Permissions?  NFS authorisation? (The server runs as root,
Juliusz> not as you.)

Not a permissions problem.  Everything is on hda.  Xft is able to
access those files.  I have taken another look.  The fonts.scale
generated by mkfontscale (20020417) assigned the same XLDF to more
than one ttf.  It also had bad weight values in the XLFDs.  (The
XftCache in that dir shows that all of the normal weight fonts are
weight=100 and the (demi)bold versions are all 200.  mkfontscale
returns a weight of thin for many but not all of the Lucida fonts
therein; it does get a couple of the right.)

I don't see that error in the ttmkfdir output, but there is probably
something of the sort

Both fonts.dir files result in exactly the same error, so there
probably *is* some problem with the ttmkfdir version as well.

-JimC




___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New versions of mkfontscale and FreeType 2 backend

[James H. Cloos Jr.]

I jus realized that there is a significant difference with the new ft2
backend.  I've lost underlining in mozilla.  I've verified that the
underlines are there when it uses its xft2 engine, but disappear with
server-side fonts.  (Something was bothering me about it last night,
but I couldn't put my finger on it until this morning.)

Oddly, though, the underlines do show up in netscape 4.7.  I'm not yet
sure why there is a difference.  I'll keep hunting

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New versions of mkfontscale and FreeType 2 backend

[James H. Cloos Jr.]

I'm running the new ft2 backend now for all scalled fonts.¹

Most everything looks good so far.  I've tried several different
fonts in mozilla, rxvt, gvim.

The average width error is still there for type1 fonts, but AFAICT
it affects very few programs that one usually doesn't notice.

SuSE patches the type1 backend to treak urw-fontspecific like
adobe-fontspecific.  (They also patch xftfreetype.c for this.)
Perhaps generalizing -adobe-fontspecific into -*-fontspecific
would be reasonable?  They have urw-fontspecific in:

/usr/share/ghostscript/fonts/fonts.dir

for the -URW-Dingbats- and -URW-Standard Symbols L- fonts.

I'm also having trouble adding /usr/lib/jdk1.3/jre/lib/fonts
to the font path.  It craps out with:

X Error of failed request:  86
  Major opcode of failed request:  51 (X_SetFontPath)
  Serial number of failed request:  8
  Current serial number in output stream:  10

which seems indicative of a broken fonts.dir.  Making a new fonts.dir
with mkfontscale;mkfontdir however did not solve that one.  I've tried
with both IBM Java 1.3's  and Sun/Blackdown 1.3.1's jre/lib/fonts.

Everything else looks great, though, whether t1, ttf or otf.

-JimC

¹ While the speedo backend is also loaded, the speedo fonts are not
  in the fontpath.  Useful, eh? :)

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New version of FreeType 2 backend

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

JC> It complains that it could not find encoding ascii-0

Juliusz> That's a ttmkfdir weirdness.

Noted.

JC> cff otf fonts still will not load.

Juliusz> I do not have access to any OpenType/CFF fonts.  If you can
Juliusz> point me to some that are available on the web, I'll see what
Juliusz> the problem is.

The only one I can find ATM is released by fontlab to demo fontlab 4:

http://www.123-fonts.com/downloads/Liz.otf

referenced off their home page .

JC> I've now also tested with the backend loaded into the x server.
JC> Type1 fonts seem to have incorrect bounding boxes, per xfd(1x)
JC> output.

Juliusz> You mean incorrect glyph metrics, or incorrect font-level
Juliusz> metrics?

[See the AVERAGE_WIDTH comments below.]

Juliusz> I know of at least one problem: I transform the Type 1
Juliusz> font-level metrics by 1000*I rather than by the font's matrix
Juliusz> as should be.  You'll get incorrect font-level metrics for
Juliusz> any font that uses a non-standard font matrix.

Of the fonts I have licensed, Lucida Bright Oblique is the only one I
can think of with a non [0.001 0 0 0.001 0 0] matrix, which obliques
by just changing the matrix.  However, my copy is in TX and offline,
and I'm not. :(  

Try each of:

:; xfd -fn '-adobe-utopia-medium-r-normal--0-240-100-100-p-0-iso8859-1'
:; xlsfonts -fn '-adobe-utopia-medium-r-normal--0-240-100-100-p-0-iso8859-1'

with the Type1 backend vs the new FreeType backend.

With the t1 backend the bounds as reported by xlsfonts are:

  bounds:   width left  right  asc  desc   attr   keysym
min7-2 0-3   -20  0x00e1
max   31 53330 8  0x03b0

but with the ft2 backend they are:

  bounds:   width left  right  asc  desc   attr   keysym
min   -7  -14025  -14025  -16384  -24249  0xff1f
max7  14025  14025  24249  16384  0x00e1

and AVERAGE_WIDTH changes from 180 to 37.  Each of the characters'
metrics are also significantly different.

It was the effect of AVERAGE_WIDTH that I saw via xfd.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New version of FreeType 2 backend

[James H. Cloos Jr.]

> "ISHIKAWA" == ISHIKAWA Mutsumi <[EMAIL PROTECTED]> writes:

ISHIKAWA> I found a typo in ftfuncs.c. This cause segv and to crash
ISHIKAWA> X server.

Cool.  That cures the segfault I was seeing.  A quick test with xfs
and fslsfonts -l gives ony two warnings.  It complains that it could
not find encoding ascii-0 and cff otf fonts still will not load.

ttmkfdir was used to generate the fonts.dir files containing ascii-0
(I didn't use mkfontscale to rebuild fonts.scale and fonts.dir...).

I've now also tested with the backend loaded into the x server.  Type1
fonts seem to have incorrect bounding boxes, per xfd(1x) output.  I
tried with arbitrary scaling, resolution, angles and shearing (ie
matrix transforms).  Would an fslsfonts output provide some help here?
Or something else?

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New version of FreeType 2 backend

[James H. Cloos Jr.]

Toon's note gave me the idea of trying xfs in gdb to track down the
segv I was weeing.  It has helped.  A segv happens in MakeAtom()
when called by FreeTypeAddProperties() as seen here:

Program received signal SIGSEGV, Segmentation fault.
0x08052def in MakeAtom ()
(gdb) where
#0  0x08052def in MakeAtom ()
#1  0x40094545 in FreeTypeAddProperties () from /usr/X11R6/lib/libXfont.so.1
#2  0x400964c0 in FreeTypeLoadXFont () from /usr/X11R6/lib/libXfont.so.1
#3  0x40096a13 in FreeTypeGetInfoScalable () from /usr/X11R6/lib/libXfont.so.1
#4  0x4005c2af in FontFileListOneFontWithInfo () from /usr/X11R6/lib/libXfont.so.1
#5  0x4005c45f in FontFileListNextFontWithInfo () from /usr/X11R6/lib/libXfont.so.1
#6  0x080511b2 in do_list_fonts_with_info ()
#7  0x0805190c in StartListFontsWithInfo ()
#8  0x0804b313 in ProcListFontsWithXInfo ()
#9  0x0804a172 in Dispatch ()
#10 0x08049fa2 in main ()
#11 0x401237ee in __libc_start_main () from /lib/libc.so.6


I *think* it is the first call to MakeAtom() in FreeTypeAddProperties()
based on the disassembply (0x1 is pushed, then 0x4, something is lea'ed
then the function call; the MakeAtom call is:

   info->props[i].name = MakeAtom("FONT", 4, TRUE);

As for why the segv occurs in MakeAtom, I cannot say.  I have verified
that the segv does not occur on the first call to MakeAtom, only (it
seems) the first call by FreeTypeAddProperties().  

The lack of debugging symbols, though, is making this difficult to
confirm.  I'll have to try w/ a -g compile.

-JimC


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New version of FreeType 2 backend

[James H. Cloos Jr.]

[SIGH]  A homogenous compile of suse's 4.2.0-61 rpm with ft2 backend
compiled instead of the ft1 backend still segfaults when rendering
most scalable fonts.  Cff otf fonts fail instead with a cannot load
/foo/bar/baz.otf error, but do not kill the server.

The only patch in suse's srpm that looks relevant is the addition of
ref counting to the module loading routines.  

I'm back to the ft1+type1 backends for now, and will test a compile of
HEAD tonight or tomorrow.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New version of FreeType 2 backend

[James H. Cloos Jr.]

Juliusz> Curious...  I don't think there are any binary
Juliusz> incompatibilities visible to drivers between 4.2.0 and
Juliusz> current HEAD.  Please do try a homogeneous recompile and tell
Juliusz> me aboput your findings.

Just managed to get the rpms compiled with the new module and patched
ft2 (only took 85 min and generated a 10MB log after a half dozen
unsuccessful attempts).

I'll try it later tonight, once I track down my archived copies of
what I now have installed to ensure I can back out. :)

A HEAD test in /usr/local will follow tomorrow or the next day.

-JimC

P.S.  Anyone else here giving it a test?

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]New version of FreeType 2 backend

[James H. Cloos Jr.]

I finally got a compile of this done.  I did it on a suse 7.3 i386 box
using their .spec file edited to add the freetype2 patch and the new
freetype backend.  I then tested with the new backend and my already
installed version of their 4.2.0 binary release.

Unfortunately, this is a no-go.  Although xlsfonts(1x) works
perfectly, any attempt to actually render a scalable font via the new
backend dies with a segfault.

The log shows very little of value.

I'll try again w/o the cross verisoning.  And also against HEAD if I
can figure out a way to do so w/o killing the current install.  (I do
not have a scratch box at hand to test on)

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]type1 backend and filenames

[James H. Cloos Jr.]

I just discovered that the Type1 backend errors out if the filename in
fonts.dir matches the glob *.PFB rather than *.pfb.  The current
FreeType backend handles majuscule extensions by including both all
minuscule and all majuscule verisons of the extension in the structure
it passes to FontFileRegisterRenderer().¹

The attached patch does the same for the Type1 backend.

-JimC

¹ Incidently even this is not a perfect solution; many people seem to
  be using an initial-majuscule plus minuscules ...  Perhaps it would
  be better were xc/lib/font/fontfile/renderers.c to match extensions
  case-insensitively?



diff -udNr HEAD/xc/lib/font/Type1/t1funcs.c JHCLOOS/xc/lib/font/Type1/t1funcs.c
--- HEAD/xc/lib/font/Type1/t1funcs.c	Sun Mar 31 05:28:55 2002
+++ JHCLOOS/xc/lib/font/Type1/t1funcs.c	Sun Mar 31 05:29:07 2002
@@ -1446,6 +1446,10 @@
   { ".pfa", 4, NULL, Type1OpenScalable,
 NULL, Type1GetInfoScalable, 0, CAPABILITIES },
   { ".pfb", 4, NULL, Type1OpenScalable,
+NULL, Type1GetInfoScalable, 0, CAPABILITIES },
+  { ".PFA", 4, NULL, Type1OpenScalable,
+NULL, Type1GetInfoScalable, 0, CAPABILITIES },
+  { ".PFB", 4, NULL, Type1OpenScalable,
 NULL, Type1GetInfoScalable, 0, CAPABILITIES }
 };

Re: [Fonts]Special Characters

[James H. Cloos Jr.]

> "James" == James A Crippen <[EMAIL PROTECTED]> writes:

James> Can Type1 fonts be larger than 256 characters though?  I
James> thought they couldn't unless they were CID-keyed, ie Type9 (or
James> whatever the hell Adobe wants to call them).

Yes, type1 can have large number of glyphs.  Only 256 of course are
available in any given encoding, but multiple encodings can be made.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

[Fonts]freetype module

[James H. Cloos Jr.]

Has anyone done any work towards porting the freetype (server-side)
font module from ft1 to ft2?

I was thinking about taking a crack at it if no one else is.

Ft2's type1 rasterizer seems to be better than X's, and support for
opentype would also be useful.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]CJK OpenType fonts?

[James H. Cloos Jr.]

> "James" == James A Crippen <[EMAIL PROTECTED]> writes:

James> I have some *big* Japanese OpenType fonts that I'd like to use
James> with X (and with TeX but that's a different matter).
James> Presumably these OpenType fonts should work with FreeType,

Just gave it a test.  Worked fine.  Just put the otf(s) in a dir
pointed to by your XftConfig and/or ~/.xftconfig file(s).

James> And is there any way to convert this OTF to say a Type1 font?
James> (TeX understands Type1, but not OTF...)  This is off topic but

It looks like pfaedit can accomplish this.  Cf: http://pfaedit.sf.net

(Hmm.  Looking closer the otf I tried is CFF encoded, so converting to
Type1 is a relatively simple operation.  For TTF outlines in an OTF,
it would probably be better to convert to Type42, yes?  I've had
success in the past using a Type42 font with TeX.  ftdump will let you
know whether the otf is ttf or cff.)

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Standard Type Service Framework (STSF): Public Review

[James H. Cloos Jr.]

> "Keith" == Keith Packard <[EMAIL PROTECTED]> writes:

Keith> Are you saying that the size of the compressed glyphs is O(s^f)
Keith> where 's' is the height of the glyphs and 1 < 'f' < 2?

For large enough scaling, yes.

Of course, this is a test of one instance each of the 256 glyphs (all
with at least some ink IIRC, but many with very little coverage) in
one serifed text font.

In each case I tested, f < 1 when i < C where i is PointSize * dpi and
C is 1400 for PK files, 2 for gzip -9 compressed GF files, approx
13850 for bzip2 -9 compressed GF files and 5700 for uncompressed GF files.

(Yes, PK hits superlinear sooner than GF does.)

All of this is for 1-bit depth fonts.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Standard Type Service Framework (STSF): Public Review

[James H. Cloos Jr.]

> "Juliusz" == Juliusz Chroboczek <[EMAIL PROTECTED]> writes:

JC> The result is that PK's compression is subliniear on this face at
JC> mag factors less than 14 and superlinear above mag factor 14.

Juliusz> PK does run-length encoding, right?

That is what I recall.

Juliusz> Then it should be linear as the point-size goes towards
Juliusz> infinity (i.e. after the effects of MF's optical scaling are
Juliusz> no longer visible).  If not, there's something weird going on.

OK.  I just figured out the (rather inane) error.  I was comparing the
file sizes to the mag factor, not to the square of the mag factor.

[SIGH] :(

Taking that into account, even the the GF files show sublinear byte
size expansion when linearly scaled (same pt size, higher dpi).

I've poking around with the datasets some more, but my hp48 is not
handy and I've not found a good package on this box to inspect the
data.  At http://www.io.com/~cloos/pk/ their are a csv and space-sv
file of the data.  The former has lables and the latter just the data.

Perhaps someone can do a better analysis of the data.

-JimC

___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts

Re: [Fonts]Standard Type Service Framework (STSF): Public Review

[James H. Cloos Jr.]

> "Jim" == Jim Gettys <[EMAIL PROTECTED]> writes:

Jim> Therefore another piece of performance data we should gather on
Jim> client side fonts is how well glyphs compress,

Out of curiosity, I just compiled 100 dpi PKs of the ec1000 from (EC
version of Knuth's Computer Modern Roman at 10pt optical) at
magnifications i <= 200, i in Z+ to see how the byte scale in
proportion to the magnification factor.

This is roughly similar to generation bitmaps at point sizes from 10
to 2000 of a typical non-optically scaled font.

As I recall, the PK format uses a simple RLE compression (it was after
all designed for *much* slower boxen than we see today :), but I have
not looked it up to confirm

The EC font has 256 (mostly) latin glyphs, and is a serif face.

I used modes.mf's mextscrn MF mode, which provies no corrections for
darkness, etc.  This is the default mode for 100 dpi in mktexpk(1),
and would typically be used to generate non-aa bitmaps for screen
viewing in X.  (For aa bitmaps, most dvi viewers use the 600 dpi
laserjet 4 mode and convert the resulting 600 dpi bitmap into a 100
dpi greymap for display.)

This is not a very scientific test, given the use of only one face,
but it does give some info.

The result is that PK's compression is subliniear on this face at mag
factors less than 14 and superlinear above mag factor 14.  It is very
close to exactly linear at mag factor 14.

I then converted the PK files to uncompressed GF files, and ran them
through 'gzip --name --best' and 'bzip2 -9'.  The gzip compressed GF
files showed sublinear growth at mag factors less than 200 and approx
linear growth at exactly mag factor 200.  Interestingly, bzip2 -9
transitions from sublinear to superliner between mag factor 138 and
139.  Of course, bzip2 has too high of a computational component for
use in this context; the update latency were it to be used to compress
glyph pixmaps for transfer from client to server would be excessive.
Even in the case of deflating the pixmaps, a faster deflate level
would be expected.

I'll put together a simple web page with the data and some graphs at
http://www.io.com/~cloos/pk/ if anyone is interested.  It should be up
by about 1800 UTC today.

-JimC


___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts