Re: [Fonts] filtered Tempest fonts
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]Dealing with standard bitmap fonts in Xft
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
Re: [Fonts]blank glyph list in fonts.config
Keith == Keith Packard [EMAIL PROTECTED] writes: Keith int0x1680/int !-- OGHAM SPACE MARK -- 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]Much worse rendering with latest fontconfig package
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]Fontconfig release - fcpackage version 2.0
I thought I sent this before, but perhaps not. I'd add dir/usr/local/share/fonts/dir to the default fonts.conf. Perhaps also dir/usr/X11R6/lib/Acrobat5/Resource/Font/dir and dir/usr/share/texmf/fonts/type1/dir are good ideas. -JimC ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig release - fcpackage version 2.0
Keith == Keith Packard [EMAIL PROTECTED] writes: Perhaps also dir/usr/X11R6/lib/Acrobat5/Resource/Font/dir 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. dir/usr/share/texmf/fonts/type1/dir 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]edit antialias=false equivalent in fonts.conf
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
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
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
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: TTGlyph name=J/!-- contains no outline data -- vs a CFF table with entries that look like this in ttx: CharString name=J -190 endchar /CharString (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]FreeType 2 backend submitted for inclusion in CVS
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
Re: [Fonts]Re: Adobe Glyph Names - Unicode 3.2 (was: Xft and MathML)
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 ?
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
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]Georgian unicode
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
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
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 version of FreeType 2 backend
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
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
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 }
};
