[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
> BTW, have we finally decided that such fonts have the extension .otb? This was discussed on the xfree86-fonts and -devel lists a long time ago (before the events), and this was definitely the best suggestion. In particular, it was only used by one obscure piece of MS-DOS software, and works on 8+3 filesystems. So I guess you might as well adopt this extension, unless someone objects loudly. > This might be worthwhile to mention in the FreeType docs and to add > to the demo programs. Aye. Juliusz ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
> It's not terribly useful for fontconfig or libXft, where it is useful is > in converting sfnt back into BDF files in case you want to take a font > and use it with old non-TTF supporting X servers. Well, that you already can do, using fstobdf (it's still in the tree, right?). Now, if there are clients that still make use of ad hoc font properties, they should be shot. Juliusz ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
> I tried fonttosfnt some weeeks ago and found that it uses
> FT_Bitmap_Size->{height,width} for ppemY and ppemX. Shouldn't it be
>
> ppemX = ppemY = FT_Bitmap_Size->y_ppem?
>
> The reason that ppemX should be equal to ppemY is that an em-sqaure with
> unequal ppems means x and y axes are scaled differently so that the
> glyphs would look stretched.
I believe that's the expected result.
x/y_ppem are the number of horizontal/vertical pixels by horizontal
em. They should normally be equal, except in the case of bitmap
strikes designed for displays with non-square pixels (such as EGA
displays).
Juliusz
___
Fonts mailing list
Fonts@XFree86.Org
http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Re: [ft] Creating an [OT]TF font from BDF font
> Being lazy, I'm asking here before actually looking around. Can anyone > recommend programs that create [OT]TF fonts from BDF fonts? > [I] seem to recall that someone on one of the Freetype lists might > have also written one; You may be thinking of my fonttosfnt. It does something completely different: it takes a BDF font (or any other format grokked by FreeType), and produces a bitmap font in a SFNT wrapper, commonly known as a ``bitmap-only TTF font''. Such fonts are not TTF fonts, they are just a way of representing bitmap data in the hightly-efficient (both space and time) SFNT format. Another way of looking at it is that they are TTF fonts that happen to lack outline data, and only have embedded bitmaps. Both FreeType and your favourite X server grok such fonts. While I warmly recommend that gbdfed should support generating such fonts (fontforge already does), this might or might not be what you want. You will find what I believe is the most up-to-date version of fonttosfnt in the X.Org CVS tree. There's also a version in XFree86, but I'm not sure it has been kept up to date. Juliusz ___ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Ugly Truetype Fonts in XFree86 4.4.0
The bytecode interpreter is disabled. http://bugs.xfree86.org/show_bug.cgi?id=666 Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Re: libfreetype-xtt2 bench
MH> I don't think it is fair however to "encourage" this by throwing MH> away useful work that someone has done, Please do not put words into my mouth, Mike. All of my replies to Chisato-san did start with the statement that doing what he's done is a good idea. I do not wish to comment on this subject any more until I've actually read the patch. It might turn out that it is perfect from all points of view, and all this discussion is in vain. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
>> What exactly are you arguing with ? DD> The notion you expressed that adding features to the freetype backend DD> goes against a goal of encouraging application developers to move to DD> client side fonts, I never said such a thing. I said that adding features to the freetype backend goes against a goal of putting core fonts into maintenance-only mode. DD> The code has been committed, and needs testing. If no significant DD> problems are found, it can remain for the 4.4 release. Good. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
DD> If you personally choose not to meet their needs (which is DD> entirely up to you, and entirely reasonable), someone else might. David, What exactly are you arguing with ? I'm saying that this code deserves being read, that nobody has appeared to do so until now (or if they did, they didn't CC the list with their opinion), and that I am busy, but will do so as soon as I've got the time. I've also been sidetracked into spelling out my opinion on core fonts, which is no secret for anyone. If you (or somebody else) has the time to read and understand Chisato's code right now, please do. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
>> The main point is that I consider core fonts to be obsolete -- client >> applications, especially internationalised ones, should move to Xft. DD> That's an issue to take up with application developers. Isn't that what we are doing? Let me reformulate this: I do not think that adding functionality to core fonts is a good way to expend developper time, particularly when I am the delopper in question. Especially so in October. >> We need to seriously consider whether inclusion of your patch goes >> against this goal. You'll understand that this is not a discussion >> that we can have before I've read and fully understood your code. DD> Achieving the goal of a single freetype backend without taking away DD> functionality that people are actually using is a good one, regardless DD> of anything else. I agree in principle. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
CY> As you said, I've worked for merging X-TT functionalities CY> and various fixes. And I've released libfreetype-xtt2 patch CY> version 1.0b. CY> Would you accept our libfreetype-xtt2 patch? If our patch CY> is accepted before XFree86-4.4 release, I think that you will CY> be able to remove freetype1 sources from XFree86's tree at CY> XFree86-4.5 release. Chisato-san, I am very glad to see TTCap implemented in the FreeType backend. The main point is that I consider core fonts to be obsolete -- client applications, especially internationalised ones, should move to Xft. This is the reason why I have basically kept the features of the FreeType backend frozen for a long time. We need to seriously consider whether inclusion of your patch goes against this goal. You'll understand that this is not a discussion that we can have before I've read and fully understood your code. Please accept my apologies for being slow, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 version 1.0 released
Chisato-san, I am sincerely sorry for not checking your code right now -- I am unfortunately a little busy currently. I will read it as soon as I've got some time, and I'll get back to you. Sincere regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Font alias
locate README.fonts Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] TTF fonts.
JB> I'm no newbie linuxuser but I've had this problem (well it's not JB> really a problem, just a thing that annoys me a lot) for all my years JB> of linux usage and have never been able to fix it. How do I get JB> truetype-fonts to look exactly as good as they do in MS Windows? http://bugs.xfree86.org/show_bug.cgi?id=666 Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Helvetica font question for Xfree86
AC> XFree86 will use either the Adobe-donated PostScript rasterizer or AC> FreeType to scale the fonts, while Xsun uses the XATM built into AC> Display PostScript, Not quite. XFree86 up to 4.2.* will use a rasteriser donated by IBM and Linotype. XFree86 4.3.* will use the FreeType 2 rasteriser. Neither is quite as good as the Adobe rasteriser, which appears to do a fair deal of postprocessing on the rasterised bitmaps. Additionally, it is quite possible that RedHat's setup uses URW++ Nimbus Sans as a substitute for Adobe Helvetica. As Paul suggested, you should keep one Sun machine and set it up to serve fonts to your local network (please see ``man fs'' on Solaris 2.5; on newer systems, it's ``man xfs''). Then, set up your XFree86 servers to only use the ``misc'' dir and the sun machine as sources of fonts. (Keeping a local misc dir will allow you to start a local server in case the font server crashes). Good luck, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE> Saying 'core fonts need to go way' is equivalent to saying EE> 'lets change the core protocol'. That's out of the question. >> I don't think the protocol spec requires the existence of any fonts >> beyond fixed and cursor. EE> Right, but this doesn't solve the real problem. Sure. I was just pointing out that the reason why we persist in maintaining the morass of the core fonts system is of a pragmatic nature, and not due to protocol requirements. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE> Generating fonts for asian character sets takes much more effort, EE> therefore it can be expected that TTCap will remain a valid EE> 'workaround' for a long time. TTCap was based on the IMHO erroneous assumption that it is better to hack extensions to fonts.dir rather than provide an extensible database for font-related information. Today, we do have just such an extensible database: fontconfig. As far as the implementation goes, TTCap lives in the font backend, which implies that somebody got the layering wrong. I do not deny that TTCap does work around real problems. However, I do not believe that TTCap is something we want to follow. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE> Saying 'core fonts need to go way' is equivalent to saying EE> 'lets change the core protocol'. That's out of the question. I don't think the protocol spec requires the existence of any fonts beyond fixed and cursor. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
DD> A practical engineering solution is about getting the results you DD> need today with the resources available. It doesn't matter if DD> TTCap one day becomes unnecessary because of the availability of DD> better fonts. Just to clarify, Yamauchi-san is referring to a TTCap field that specifies the metrics of glyphs in a given range. The core protocol requires that the metrics of all glyphs be computed at font open time (actually at QueryFont time). In practice, this requires rasterising all glyphs in a font when opening a font, which for large fonts can take up to a few minutes. To work around this problem, both X-TT and freetype trust the fonts.dir file when the spacing is -c-. While this works well with ideographic fonts from the 1990s, it doesn't help with modern fonts, which tend to have proportional Latin glyphs. This extension is orthogonal to X-TT's ability to slant or bolden fonts, which is what I believe you (David) are referring to. (It is my opinion that the proper workaround is to have a general mechanism that allows caching of glyph metrics across font instantiations, and it wouldn't be difficult to convince Keith to add such an interface to fontconfig. I do not believe that fonts.dir is the right place to store such information.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
JS> Well, X-TT's 'competitor' is not freetype module, but fontconfig JS> (+FT2 + Xft) Hear, hear. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
CY> But do XFree86's developers accept our patches for libfreetype.a? I do not believe that TTCap is a good idea, and will not implement it in the FreeType backend. The way to go is to implement all font configuration through fontconfig. Unlike fonts.dir, the fontconfig cache is an extensible data structure that can be used to store any relevant information. A very rough beginning can be found on http://www.pps.jussieu.fr/~jch/software/files/fcfpe.c Please do not redistribute this code yet, and let me know if you want to hack at it. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] After-XTT's extension of the encoding field.
EE> There is a subsetting mechanism already (see XLFD specs), you can EE> use a bracket notation like : ...-iso8859-1[65 70 80_90] means only EE> use glyps 65, 70, 80-90. I don't know if this has ever been EE> implemented with any renderer. It is implemented in all of our renderers with the exception of the bitmap scaler. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Encodings XLFDs within sfnt
In order to preserve bitmap font names as we switch to sfnt for XFree86, I need to have fonttosfnt put the original font name in some place where mkfontscale can find it. The proper way would be to formally define a new sfnt table, for example ``XF86''. However, I think it is simpler and quite as reliable to put a non-standard signature in some standard place. I'm currently tempted to use the ``comment'' string in the ``name'' table. I could generate it to be XFree86 font, original name was -misc-fixed-... and then check for this string. Comments? Better ideas? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Bitmap-only SFNTs: initial code in CVS
> 4. Convert all the fonts to bitmap-only sfnt, and give them the
>extension ttf (for now -- see my next message):
>
> $ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
> $ rm *.pcf
Sorry, forgot an important step: transcoded fonts should be removed,
on-the-fly transcoding will happen.
$ rm *-*-*.pcf
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Choosing an extension for bitmap-only SFNTs
I need to pick an extension for the bitmap-only SFNT fonts[1]. While these fonts use the same file format as TrueType and OpenType fonts, they do not fullfill the requirements of any of the four (!) TrueType specifications. Apple calls them ``sfnt-wrapped bitmap fonts'', pfaedit calls them ``bitmap-only TTF fonts'', and Microsoft do not call them at all. These fonts are refused by Windows XP. Because users expect files with a ttf or otf extension to contain scalable fonts, they need to have a different extension. Such fonts are used by Apple (who do not use file extensions), but not by Microsoft (who do); hence, I believe I need to pick a new one. I suggest they should have the extension ``.sfnt'', with ``.sfn'' being recognised for compatibility with 8+3 systems. Opinions collected so far: - David Dawes doesn't have an opinion either way, but he'd like me to consult with this list first. - Egbert Eich would prefer ``.sfn'' to be the default, as he believes this will lessen his support load. (He's probably right, but I dislike making MS-DOS the default.) I'll probably submit code to handle the new extension these next days, and would be glad to hear from you as soon as possible. Juliusz [1] http://www.pps.jussieu.fr/~jch/software/xfree86-bitmap-fonts.html ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Bitmap-only SFNTs: initial code in CVS
It is now possible to use bitmap-only SFNTs in XFree86. There is very
little left to do at the server level, some more work is needed at the
level of fonttosfnt and mkfontscale.
0. Check you've got the right version of XFree86.
$ cvs log xc/lib/font/fontfile/fontdir.c | grep 289
289. Twisting fontfile.c and fontdir.c to be able to pass all fonts (bitmap
1. Apply
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=491
and rebuild mkfontscale.
2. Make a directory full of fonts.
$ cd /tmp
$ mkdir fonts
$ cd fonts
$ cp /usr/X11R6/lib/X11/fonts/misc/*.pcf.gz .
3. Uncompress the fonts. This is optional, but if you don't do that,
the next step will take minutes rather than seconds.
$ gzip -d *.pcf.gz
4. Convert all the fonts to bitmap-only sfnt, and give them the
extension ttf (for now -- see my next message):
$ for i in *.pcf; do fonttosfnt -o ${i%.pcf}.ttf $i ; done
$ rm *.pcf
You will get a number of failures, I'm looking into that.
5. Create a fonts.dir file:
$ mkfontscale -b
You'll get some warnings, and some of the generated names will not be
quite right. Additionally, all non-Unicode fonts will get names
ending in ``microsoft-symbol''. (Fixing that will require private
extensions to the sfnt format.)
6. Test the new fonts.
$ xset +fp `pwd`
$ xlsfonts -ll -fn '-misc-fixed-medium-r-normal--20-*-75-75-m-*-iso8859-1' | grep
RASTERIZER_NAME
RASTERIZER_NAME FreeType
$ xfd -fn '-misc-fixed-medium-r-normal--20-*-75-75-m-*-iso8859-1'
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Someone has re-implemented ucs2any.pl in C
AK> It's worth considering including this in the XFree86 tree, if the AK> server-side re-encoding is a long way from being complete. It's done, actually, although not entirely committed yet. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Mkfontdir is dead?
On http://www.pps.jussieu.fr/~jch/software/files/mkfontscale-20030605.tar.gz you will find a version of mkfontscale which in theory should subsume the functionality of mkfontdir. It should be possible to replace mkfontdir with a script that does #!/bin/sh mkfontscale -b -s -l "$@" and not have anyone notice any change (except that it's slightly faster). Please do test. I want to kill mkfontdir soon. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] [PATCH] restore the sign of UNDERLINE_POSITION in FreeType rasterizer
RK> Any reason this patch hasn't been applied yet? It's filed in the list of patches to apply, under your name, and with my taking responsibility for it being correct. It will be applied as soon as someone has time to do so. You know, there's just been a release, and most of the committers are taking a break. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] is it possible the spacing of embedded bitmap fonts
KP> The glyph spacing is set as a part of each embedded glyph image; Calls for a fontconfig option to use the scalable spacing for embedded bitmaps? DPS used to have that. (Actually, if memory serves, it was a three-state switch: use bitmap metrics, use scalable metrics, and use bitmap metrics with retouching in order to get scalable metrics on average. How they did that in a procedural API is beyond me.) KP> it appears that the font you're using is just broken. I beleve KP> you can probably use pfaedit to both verify this and even fix it. Current pfaedit will drop the instructions (hints). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] [PATCH] restore the sign of UNDERLINE_POSITION in FreeType rasterizer
RK> In FreeType font rasterizer the sign of the XLFD property
RK> UNDERLINE_POSITION has changed between 4.2.1 and 4.3.0. Because of
RK> this, Type1 and TrueType fonts now have UNDERLINE_POSITION negative,
RK> which makes gtk1 builds of mozilla loose underlining.
Yep, this is right. UNDERLINE_POSITION counts downwards, which is not
stated explicitly by the XLFD, but clearly implied by the formula in
3.2.30:
UNDERLINE_POSITION = ROUND(maximum_descent / 2)
David, please apply and attribute to Roman Kagan.
Juliusz
--- xc/lib/font/FreeType/ftfuncs.c~ 2003-02-13 06:01:45.0 +0300
+++ xc/lib/font/FreeType/ftfuncs.c 2003-03-04 20:27:16.0 +0300
@@ -959,11 +959,11 @@
int underlinePosition, underlineThickness;
if(post) {
-underlinePosition = TRANSFORM_FUNITS_Y(post->underlinePosition);
+underlinePosition = TRANSFORM_FUNITS_Y(-post->underlinePosition);
underlineThickness = TRANSFORM_FUNITS_Y(post->underlineThickness);
} else {
underlinePosition =
-TRANSFORM_FUNITS_Y(t1info->underline_position);
+TRANSFORM_FUNITS_Y(-t1info->underline_position);
underlineThickness =
TRANSFORM_FUNITS_Y(t1info->underline_thickness);
}
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] filtered Tempest fonts [OT]
That's fun. MK> Sure, if that's feasible to implement. Yes, it's easy. And it doesn't break the protocol. Shadowfb, you introduce noise upon blasting to the real framebuffer. Because, GetImage and friends work from the shadowfb, you're not breaking the protocol. You might actually end up with an implementation that is not measurably slower than stock shadowfb. (That's my interpretation of the protocol: an X server that produces a black screen does respect the protocol, as long as GetImage returns the right data. Your interpretation may differ.) Now of course you need to look out for your shadowfb RAM broadcasting ;-) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] filtered Tempest fonts
GSO> PS A quick plug for the other item on my 'OpenSource the computing GSO> environment for Legal work' wish list. A document processor that GSO> numbers paragraphs That's a question for comp.text.tex. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] filtered Tempest fonts
MK> - Lowpass filtering the glyphs in horizontal direction Why the glyphs? Wouldn't you want to do that for everything that's displayed? MK> - Replace the least few significant bits with pseudo-random bits for each MK> usage of a glyph on the screen. Are you implying that what the eavesdroppers get is the derivative of the signal rather than the signal itself? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] filtered Tempest fonts
MK> Putting an anti-tempest filter into freetype2 has been on my todo list MK> for a long time Could you guys be so kind as to tell us mere mortals what you're speaking about? It's got something to do with deploying XFree86 in the American embassy in Moscow, right? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Re: A serious problem about "freetype" module
>> Could you please try reverting your patch and trying out the attached? CY> Ok. I confirmed that your patch also prevent the crash. Great, thanks. Submitted. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Re: A serious problem about "freetype" module
Could you please try reverting your patch and trying out the attached? It checks for rounding errors explicitly rather than introducing a one-pixel fuzz value. Thanks for your help, Juliusz Index: xc/lib/font/FreeType/ftfuncs.c === RCS file: /cvs/xc/lib/font/FreeType/ftfuncs.c,v retrieving revision 1.25 diff -c -r1.25 ftfuncs.c *** xc/lib/font/FreeType/ftfuncs.c 2002/10/02 15:06:12 1.25 --- xc/lib/font/FreeType/ftfuncs.c 2003/02/12 15:56:42 *** *** 595,601 if(wd <= 0) wd = 1; if(ht <= 0) ht = 1; } ! /* Note that wd >= bitmap->width and ht >= bitmap->rows */ bpr = (((wd + (instance->bmfmt.glyph<<3) - 1) >> 3) & -instance->bmfmt.glyph); --- 595,606 if(wd <= 0) wd = 1; if(ht <= 0) ht = 1; } ! ! /* Make sure rounding doesn't cause a crash in memcpy below */ ! if(wd < bitmap->width) ! wd = bitmap->width; ! if(ht < bitmap->rows) ! ht = bitmap->rows; bpr = (((wd + (instance->bmfmt.glyph<<3) - 1) >> 3) & -instance->bmfmt.glyph); Index: xc/lib/font/FreeType/module/ftmodule.c === RCS file: /cvs/xc/lib/font/FreeType/module/ftmodule.c,v retrieving revision 1.13 diff -c -r1.13 ftmodule.c *** xc/lib/font/FreeType/module/ftmodule.c 2002/10/01 00:02:11 1.13 --- xc/lib/font/FreeType/module/ftmodule.c 2003/02/12 15:56:58 *** *** 44,50 MODINFOSTRING1, MODINFOSTRING2, XF86_VERSION_CURRENT, ! 2, 0, 1, ABI_CLASS_FONT, /* Font module */ ABI_FONT_VERSION, MOD_CLASS_FONT, --- 44,50 MODINFOSTRING1, MODINFOSTRING2, XF86_VERSION_CURRENT, ! 2, 0, 2, ABI_CLASS_FONT, /* Font module */ ABI_FONT_VERSION, MOD_CLASS_FONT,
Re: [Fonts] A serious problem about "freetype" module
Can you reproduce this bug with ftview? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Unsafe chars in Mkfontscale
Mike,
Would you be so kind as to test the attached patch and confirm that it
does what you want? It's rather urgent, I'd like it to go into 4.3.
I'm cut off from CVS right now, sorry if it doesn't apply cleanly.
Juliusz
*** xc/programs/mkfontscale/mkfontscale.c.old 2003-01-27 15:58:08.0 +0100
--- xc/programs/mkfontscale/mkfontscale.c 2003-02-06 17:38:53.0 +0100
***
*** 299,304
--- 299,345
return c;
}
+ static int
+ unsafe(char c)
+ {
+ return
+ c < 0x20 || c > 0x7E ||
+ c == '[' || c == ']' || c == '(' || c == ')' || c == '\\';
+ }
+
+ static char *
+ safe(char* s)
+ {
+ int i, len, safe_flag = 1;
+ char *t;
+
+ i = 0;
+ while(s[i] != '\0') {
+ if(unsafe(s[i]))
+ safe_flag = 0;
+ i++;
+ }
+
+ if(safe_flag) return s;
+
+ len = i;
+ t = malloc(len + 1);
+ if(t == NULL) {
+ perror("Couldn't allocate string");
+ exit(1);
+ }
+
+ for(i = 0; i < len; i++) {
+ if(unsafe(s[i]))
+ t[i] = ' ';
+ else
+ t[i] = s[i];
+ i++;
+ }
+ t[i] = '\0';
+ return t;
+ }
+
int
doDirectory(char *dirname_given)
{
***
*** 484,489
--- 525,534
if(!adstyle) adstyle = "";
if(!spacing) spacing = "p";
+ /* Yes, it's a memory leak. */
+ foundry = safe(foundry);
+ family = safe(family);
+
for(encoding = encodings; encoding; encoding = encoding->next)
if(checkEncoding(face, encoding->value)) {
found = 1;
Re: [Fonts] mkfontscale and family names which contain '-'
MF> Maybe one should work around that problem in mkfontscale by replacing MF> the '-' characters with ' ', for example like that: You're right, of course. Thanks for the report. I'll change your patch a wee bit: I'll copy the family name instead of modifying it in place, and I'll do the replacement by hand -- strpbrk is likely to break some obscure platform or other. I'll send it in ASAP. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts] Fix mkfontscale crash (please include in 4.3)
Two extra guards in mkfontscale:
- prevents mkfontscale from looking at bitmap fonts;
- ensures mkfontscale doesn't crash if a font happens to have no head.
Please apply for 4.3.
Juliusz
? xc/programs/mkfontscale/Makefile
? xc/programs/mkfontscale/fonts.scale
? xc/programs/mkfontscale/mkfontscale
? xc/programs/mkfontscale/mkfontscale.1x.html
? xc/programs/mkfontscale/mkfontscale._man
Index: xc/programs/mkfontscale/mkfontscale.c
===
RCS file: /cvs/xc/programs/mkfontscale/mkfontscale.c,v
retrieving revision 1.2
diff -c -r1.2 mkfontscale.c
*** xc/programs/mkfontscale/mkfontscale.c 2002/09/27 01:55:06 1.2
--- xc/programs/mkfontscale/mkfontscale.c 2003/01/22 22:21:26
***
*** 349,354
--- 349,358
ftrc = FT_New_Face(ft_library, filename, 0, &face);
if(ftrc)
continue;
+
+ if((face->face_flags & FT_FACE_FLAG_SCALABLE) == 0)
+ continue;
+
found = 0;
foundry = NULL;
***
*** 435,440
--- 439,454
slant = head->Mac_Style & 2 ? "i" : "r";
if(!weight)
weight = head->Mac_Style & 1 ? "bold" : "medium";
+ }
+
+ if(!slant) {
+ fprintf(stderr, "Couldn't determine slant for %s\n", filename);
+ slant = "r";
+ }
+
+ if(!weight) {
+ fprintf(stderr, "Couldn't determine weight for %s\n", filename);
+ weight = "medium";
}
if(!foundry) {
Re: [Fonts] mkfontscale dumps core on .pcf, .pcf.gz or .bdf files
MF> mkfontscale dumps core on .pcf, .pcf.gz or .bdf files: Yes. (Actually on all bitmap-only fonts.) MF> Here is a tentative patch which fixes the problem for me: No, you're fixing a symptom. All bitmap-only fonts should be ignored, with no reference to their extension. I'll submit a patch in time for 4.3. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] xfd(1) from 4.2.0 won't read AbiWord 1.0.1 font names
J> AbiWord could not load the following font or fontset from the X Window J> System display server, [-*-Times New Roman-regular-r-*-*-*-0-*-*-*-*-*-*] J> Though I wonder about the spaces in the typeface name, That's no problem. J> - just what is `XError ... 86'? $ grep 86 xc/include/fonts/font.h xc/include/fonts/font.h:#defineBadFontPath 86 That's the generic, catch-all font-related error. The most common errors are described in the ``Troubleshooting'' section of README.fonts. Please see http://www.xfree86.org/current/fonts2.html#9 Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] New Adobe glyphlist.txt
MK> They have added a very large number of new glyph names, but they did not MK> change the mapping of their private-use-area characters that have been MK> added to Unicode in the mean time. They have in a few cases. Check for instance the Zapf Dingbats mapping. MK> The format of the file has changed! It's now a one-to-many mapping, which may require changes to data structures (Cedilla 0.3 will cons very slightly more than the previous version). In cases where a codepoint has multiple names, there's no indication which is the preferred one. Font editors, for example, will need to make an arbitrary choice. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Disable anti-aliasing
BM> 2) Is there a recommended overview on fonts under X For 4.2 (doesn't include Xft info), http://www.xfree86.org/current/fonts.html For 4.3 (includes Xft info that doesn't apply to 4.2), http://www.pps.jussieu.fr/~jch/software/fonts-doc/ Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: X-TT and OTF
ES> Microsoft says that fonts with CFF data or fonts containing TrueType ES> outlines that have OpenType layout tables should use the "otf" ES> extension otherwise the "ttf" extension should be used. >From the OpenType spec: Filenames OpenType fonts may have the extension .OTF or .TTF, depending on the type of outlines in the font and the creator's desire for downlevel compatibility. * Fonts with CFF data always have an .OTF extension. * Fonts containing TrueType outlines should use the .TTF extension to enable the font to be used under older versions of Windows. Placing a DSIG table in a .TTF makes it an OpenType font. In the shell of OpenType-enabled systems, the font will be enumerated with an OpenType icon, even without an .OTF extension. However, an .OTF extension can be used if downlevel- compatibility is not an issue. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: some fonts apparently cannot be displayed with the new "freetype" module
MF> XFree86 CVS version 20021219. The omegaserif fonts cannot be MF> displayed using the new freetype2 based "freetype" of XFree86 MF> anymore: Do they work with ftview of FreeType 2? Does the log file have something to say? (The FT2 backend is somewhat more verbose than the FT1 one.) I won't have time to work on that myself before a couple of weeks. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: X-TT and OTF
Mike, You do realise I've got nothing to do with X-TT, right? X-TT bugs should not be sent to me, but to whoever is the X-TT maintainer today. MF> This seems to be caused by the new OpenType fonts which are now MF> distributed with XFree86. "xtt" apparently doesn't like the .otf MF> extension. When renamed to .ttf, "xtt" works and can display MF> these fonts. I.e. probably something must be fixed in "xtt" to MF> make it handle fonts with the .otf file name extension correctly MF> as well. X-TT does not deal with OTF/CFF fonts. It does deal with TTF fonts. According to what you say, these are OTF/TTF fonts with the ``otf'' extension. According to Microsoft, OTF/TTF font files should have the ``ttf'' extension. Thus, apparently, the fonts included with XFree86 should be renamed to ttf. Before submitting a patch to do that, you should double-check that they are indeed TTF files. For example, use ttfdump (from ftp.freetype.org) to check whether they have a ``glyf'' table. 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. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Will 4.3.0 get rid of 8bit bitmap fonts?
>> 1. find somebody who can debug Windows to find out why the fonts >> generated by fonttootf don't work on that platform; JC> I should note that pfaedit saves differently depending on Mac or JC> Windows formats. No, I'm using the Windows format for embedded bitmaps. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Will 4.3.0 get rid of 8bit bitmap fonts?
MH> There has been much discussion in the past of getting rid of the MH> ISO8859-* bitmap fonts generated by ucs2any et al. The last MH> discussion I recall on this was that ttf font file format would MH> be used with embedded bitmaps. Is this still planned for 4.3.0? I'm far from ready. Here's the things that remain to be done, in no particular order: 1. find somebody who can debug Windows to find out why the fonts generated by fonttootf don't work on that platform; 2. modify fonttootf to properly generate font-level metrics (they are currently hardwired for fixed); 3. modify mkfontscale to generate bitmap entries for bitmap fonts; 4. modify the FreeType backend to do reasonable things with bitmap entries. I need help for 1 -- I'm just not competent to deal with it. 2. is simple but tedious, and will require hacking at FreeType to get access to BDF properties. 3 is ready in my private tree (I'll probably want to rework it), 4 is really not difficult. Additionally, I'll probably want to modify the FreeType backend to discard faces associated to open fonts when they've not been used for some time. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Draft XFree86 4.3 fonts documentation
On http://www.pps.jussieu.fr/~jch/software/fonts-doc/ you will find a draft version of the fonts docs that I'm hoping to get into 4.3. I'd be grateful if people could proofread it and check that the examples actually work. I am *not* interested in output from an automated spellchecker. I don't trust these coputer things. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Dealing with standard bitmap fonts in Xft
KP> The goal here is to make sure the user has some way to configure KP> whether to permit bitmap fonts to appear on the screen even when KP> an application specifically requests a bitmap only family. It's not clear to me whether such a feature should be under control of the config file, of the application, or both. (Actually, as far as font selection goes, nothing is quite clear to me, but that's a different story.) I would also like to request that the default should be false, but I don't have strong feelings about that. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Dealing with standard bitmap fonts in Xft
KP> but I'd prefer a simple way to avoid using bitmap fonts KP> when any outline face exists that supports the requested language. KP> Is this a reasonable request? Not for me. For many applications I prefer bitmap fonts to scalable fonts, and I wouldn't be willing to switch to Xft throughout my desktop if Xft prevented me from using the fonts I'm used to. Keith, please don't do that. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Xprint
I think we've strayed from the initial subject. I've got no objection to Mozilla using Type 42 CIDFonts, Type 100 halftones, Type 4 images and an embedded APL interpreter. Whatever. As long as they don't use Xprint. JC> their choice to use Type 42 CIDFonts JS> Given that truetype fonts are much easier to come by than genuine JS> CID-keyed fonts It's funny how we come to opposite conclusions from the very same facts. Because TTFs are plenty, one needs to support them well on all printers. Thus, one should not require the support for Type 42 CIDFonts. But I really have no problem with that. Font format conversion can always be added at a later stage. JS> I also thought that's the case. However, Brian Stell changed the JS> plan (see http://bugzilla.mozilla.org/show_bug.cgi?id=144663. ) JS> and he's now gonna use type 8 (neither type 11=what you're calling JS> type42 CIDFont = CIDFont type2 nor type 42). Yes, the terminology is confusing. To be pedantic, I was speaking of serialised CIDFont resources with a CIDFontType of 2 and a FontType of 11, which happens to contain Type 42 charstrings. JS> What's type 8 font, btw? No idea. I can't find them either in either PLRM 3 or the 3012 supplement. Are you sure you're not thinking of Type 0 fonts (composite fonts) with a FMapType of 8, which is what Adobe used in the Japanese market before they came up with CIDFonts? These will work on all level 2 devices (possibly requiring that a proprietary Adobe procset be downloaded) and on Japanese level 1 devices. In my humble opinion, Type 0 fonts are a hack for doing in the PS interpreter something that really ought to be done in the host (font switching). But then, Mozilla is written in C++, and it may be simpler to implement font switching in PostScript ;-) JS> I also thought that you prefer to leave as much as possible for PS JS> printers to take care of. There's a compromise to make between how much information you want to give the PS interpreter and how portable you want to be. I think that using Type 42 CIDFonts (whatever you may think of my terminology) with an option to use Type 1 base fonts is the sweet spot. >> Conversion to Type 1 fonts works everywhere, gives excellent results, >> and the code is readily available (ttftpt1). JS>Does this conversion code also work for large CJK ttf fonts(with more JS> than 256 glyphs)? Or, does it also support conversion to composite JS> font(OCF?)? Yes. Yes. Although with very large fonts you may run out of memory on very old PS devices if you're not careful. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Xprint
JC> although I'm a little bit suprised at your enthusiasm for the thing. JS> I'm not so enthusiastic about it as you may think. Sorry for mis-reading your mail, then. (For my defence, I did state my surprise.) JS> Nonetheless, [Xprint] works _now_. Point taken. JS> As for complex script rendering, it's possible... You'll doubtless agree with me that what you're describing are a workarounds for the intrinsic limitations of Xprint -- more usually known as hacks. Cunning schemes such as that have existed under X11 for decades now -- it's high time to move on. JC> There is also no way[1] how Xprint could implement dynamically JC> generated fonts, as required for example by CSS2. JS> I'm a bit confused as to what you meant by 'dynamically generated JS> fonts'. Fonts that are not permanently installed in the system, but are dynamically generated by the application from e.g. data downloaded through HTTP (as with ``web fonts''), data embedded within data structures (as with PDF) or even dynamically computed data. So yes, we did think of the same thing. JC> incrememtal uploading of fonts to the printer at the PS level JS> provided that the font resolution mechanism is tied with fontconfig Goes without saying. JC> I'm a little bit suspicious about their choice to use Type 42 CIDFonts JS> Given that truetype fonts are much easier to come by than genuine JS> CID-keyed fonts for CJK (which is also true of truetype fonts vs PS JS> type 1 fonts for European scripts although to a lesser degree), I guess JS> the choice is all but inevitable... I may have misunderstood something, but last time I checked the approach was to use Type 42 CIDFonts *only*. These are currently a fairly rare beast (only supported since version 3012, if memory serves). PostScript supports a dozen or so font formats, but the only ones that are supported on all implementations are Type 1 and Type 3 fonts (not CIDFonts). I think that nowadays Type 1 and Type 3 CIDFonts can be taken for granted. There are at least four ways of dealing with TTFs in PS. Type 42 CIDFonts is the most efficient, and should most definitely be used by folks with new printers. Type 42 fonts (not CIDFonts) are supported since version 2017 and are barely slower than Type 42 CIDFonts. Conversion to Type 1 fonts works everywhere, gives excellent results, and the code is readily available (ttftpt1). Finally, if everything else fails, you can always download a Type 3 bitmap version; this should only happen at the user's explicit request. As you see, I am not arguing against support for CIDFonts; I'm merely stating that making Type 42 CIDFonts the only download format for TTFs makes me er... suspicious. JC> [using Type 42 CIDFonts] will require many users to rasterise JC> everything with ghostscript on the host, with all the ensuing JC> performance and printing quality issues. JS> Well, that's not so bad as you think. What percentage of JS> average Linux(or other free Unix) users do you think own a JS> postscript printer? I don't know, and I don't care. I'm opposed to the private ownership of the means of production. Seriously, though: where I live, most people don't own a printer at all. For printing, they take a floppy to their place of work or study, or carry it to the closest print shop. As people don't usually know what kind of printer they will end up printing on, portable PostScript is needed. JS> How about something like XftPS on 'the client side'? Absolutely. It's a mere matter of hacking. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Xprint
JS> Even with this weakness, Xprint is by far the best printing JS> solution available at the moment for Mozilla under Unix/X11 JS> because postscript printing module of Mozilla does not work very JS> well yet Xprint might work for CJK fonts, although I'm a little bit suprised at your enthusiasm for the thing. There is no way, though, how Xprint could work for complex scripts without standardising on glyph mappings. There is also no way[1] how Xprint could implement dynamically generated fonts, as required for example by CSS2. The right approach is obviously to do incrememtal uploading of fonts to the printer at the PS level, as the Mozilla folks are trying to do. I'm a little bit suspicious about their choice to use Type 42 CIDFonts for that, though, as it will require many users to rasterise every- thing with ghostscript on the host, with all the ensuing performance and printing quality issues. Juliusz [1] Without a major protocol extension. Way, way more complex than what Xft does -- basically you'd have to duplicate the most complex part of PS, the font interfaces, at the X11 protocol level. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]fontconfig.org
J> Dear webmaster of fontconfig.org and webmaster of J> xfree86.org/current/fonts.html, Juliusz Chroboczek I'm merely the author of the latter document. I am not a web site maintainer (which I take is what ``webmaster'' means). J> 1) Please mention xft and FontConfig on this page, and describe what J> they are for, and how they relate to the rest of the information on J> www.xfree86.org/current/fonts.html The document does explicitly state that RENDER fonts are not described. They will be in 4.3.0 if I have time to write a section. Help is of course warmly welcome -- I didn't find anything on fontconfig.org that is suitable for verbatim theft. J> In both cases you may consider to describe the mechanism of how a J> font-family choice (e.g. on a web-page) propagates to a unique fully J> specified X font-name of an installed font to be used to render the J> font (on the web-page). Why do you believe that an XFree86 document should describe how your web browser works? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]FreeType and .pcf.gz
For your information, FreeType 2.1.3 has been announced. I haven't tested it yet, but it claims to implement compressed PCF fonts. It also claims to fix the BDF bearings problem. It doesn't claim to fix the PCF resolution problem. If anyone has time to test it, please report. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale again
GC> Given that mkfontscale can handle multiple directories with one GC> invokation, I would not lean toward your current approach. >> Sorry, I'm not following. Could you please be a wee bit more explicit? GC> With ttmkfdir you can do: GC> ttmkfdir -d /usr/share/fonts/dir1 -o /usr/share/fonts/fonts.scale GC> ttmkfdir -d /usr/share/fonts/dir2 -o /usr/share/fonts/test.scale GC> and fonts.scale is created in the first directory but test.scale GC> is created in the second. I understand that. I was confused by the use of ``given'' in your first statement. Mkfontscale works that way because I want it to be consistent with mkfontdir. If you have an extension to that behaviour to suggest, I'm listening. One possibility would be a -o flag that only makes sense when no more than one directory is specified. Would that significantly increase your happinness? (You have to consider that hacking command-line parsers significantly decreases mine, and we have to make sure that the total amount of happinness in the universe remains at least constant.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Problems with Xft and pcf/bdf fonts...
P> The font is supposed to be 6x13, would 13x13 be incorrect and P> that's why it can't draw it properly? No, 13x13 is correct. Read my previous explanation again. What happens when you use the BDF version? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale again
GC> It is not clear to me which way is better (or worse). Given that GC> mkfontscale can handle multiple directories with one invokation, I GC> would not lean toward your current approach. Sorry, I'm not following. Could you please be a wee bit more explicit? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Problems with Xft and pcf/bdf fonts...
available_sizes-> height = 13 available_sizes-> width = 13 P> Does this sound right at all? This is correct. P> You've mentioned fontconfig. Should I be using that to make P> life easier (cos I'm not using that lib for the moment)? Yes. Fontconfig is the only way to end the Unix Font Hell. (The situation in which every application has a different way for searching for fonts.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale again
KP> Fontconfig uses a precise scheme to measure language coverage; it has KP> required characters for languages including Korean, Chinese (Big5, GB18030 KP> and Big5+HKS) and Japanese. Would that be of any use to mkfontscale? Quite likely. Could you please point me at the code? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Problems with Xft and pcf/bdf fonts...
>> Worse than that. The pixel size must match in both the X and the Y >> direction. (FreeType and, to a certain extent, X11 support non-square >> pixels). P> Hmm so what exactly I can try in this particular case? Please check the FT_Bitmap_Size structure. It has two components, the size in the X direction and the size in the Y direction. You should walk the available_bitmaps array of the FT_Face structure and make sure that the size you requested is available. I believe that doing that should be under the responsibility of fontconfig. There is a lot of confusion about what these dimensions mean, so let me explain. With every font is associated an arbitrary dimension known as a quad. When you request an eight-point instance of a font, you request the font to be scaled so that one quad is eight points. A bitmap strike in TTF (and hence in FreeType) is described by the size of the em in units of one pixel. If pixels are square, that's well defined. If pixels are non-square, the value depends on whether you use the width or the height of pixels to measure; hence the two values in FT's FT_Bitmap_Size. The thing to know is that a strike designed for square pixels has the same X- and Y- sizes. The other thing to know is that the BDF driver in current FreeType releases is buggy in assigning the size 8 by 13 to the X11 font called ``8x13''. And I hate Macintosh keyboards. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale again
GC> Now ttmkfdir has a -m (--max-missing) command line parameter which is GC> described as "max # of missing characters per encoding, default is 5". Mkfontscale has two distinct ways of operating, one for eight-bit encodings, one for large encodings. For eight-bit encodings, mkfontscale decides which characters are important, and will only generate entries for fonts that cover all the important characters. There's a specific notion of what is important for KOI fonts, a different one for other fonts. For example, both mkfontscale and ttmkfdir will consider that a font with no non-breaking space covers Latin 1, but for very different reasons: mkfontscale considers nbsp to be unimportant, while ttmkfdir merely notices that fewer than 5 characters are missing. They will give different results for a font missing capital A: ttmkfdir will accept it, while mkfontscale will reject it on the grounds that A is too important to live without. For large fonts, deciding which characters are important is beyond my competence, so I implemented a scheme similar to the one in ttmkfdir, which is controlled by the -f (fuzz) flag to mkfontscale. I hope the above makes sense. If you have any particular examples where it yields bad results, please inform me. GC> While I am talking about these two programs, I do prefer the way GC> ttmkfdir creates its output better than mkfontscale -- mkfontscale GC> creates the font.scale file in the directory it is scanning GC> whereas ttmkfdir outputs to stdout which can be redirected via the GC> -o (--output) command line parameter. Mkfontscale can do multiple directories in a single run, so you'll have to specify the exact behaviour that you want. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Problems with Xft and pcf/bdf fonts...
>> This is the behaviour you get with FreeType when you open a >> bitmap-only font and try to draw at sizes not included in the font. >> You need to make sure the size you're requesting is one that appears >> in the font (by walking the strikes array of the face). P> Do you mean the XFT_PIXEL_SIZE? I just did a quick try of of P> loading from size 1 to 50 but it didn't help either. Worse than that. The pixel size must match in both the X and the Y direction. (FreeType and, to a certain extent, X11 support non-square pixels). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Problems with Xft and pcf/bdf fonts...
P> However, XftDrawString8 and XftDrawStringUtf8 are not drawing P> anything. This is the behaviour you get with FreeType when you open a bitmap-only font and try to draw at sizes not included in the font. You need to make sure the size you're requesting is one that appears in the font (by walking the strikes array of the face). Or does Xft do the check for you? Additionally, there are a couple of size-related bugs in the bitmap backends of FreeType. I'll try to get them fixed in time for 4.3.0. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]font renderer for .pfa/.pfb registered more than once
MH> Nov 11 01:30:49 jik xfs: Warning: font renderer for ".pfa" MH> registered more than once That's expected behaviour with current CVS, which is not internally consistent. Both the freetype and the type1 backends register for PostScript fonts; whichever you get depends on the order they register. MH> Is this something to consider a bug? Could you please try again after applying http://www.pps.jussieu.fr/~jch/software/files/xfree86-fonts-priority-20021025.patch Assuming it works today, it will cause the freetype backend to get Type 1 fonts, and the type1 backend to get CFF fonts. Thanks, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Priority for core fonts renderers
Would people bee so kind as to test the following before I submit it? http://www.pps.jussieu.fr/~jch/software/files/xfree86-fonts-priority-20021025.patch In theory, it should allow you to load all of the "type1", "freetype" and "xtt" modules with conflicts being handled gracefully. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Core fonts issues [was: Problems with Type1 big fonts]
DD> Unless the old Type1 backend can unreservedly be replaced by the new DD> FreeType2 backend, then it should be disabled, and maybe even a "fake" DD> type1 font module created for the modular build so that existing DD> configurations don't break. If there are still reasons for wanting the DD> old backend, then it needs to be configurable, at least at build-time. DD> If we want to provide more flexibility in allowing the user to control DD> what font suffixes are handled by what backend, there would need to be DD> some type of run-time configurability. I was looking into that when other things came up; I may very well be able to come back to this. Anyway, here's the plan I had. The idea would be to have a new interface, Bool FontFileRegisterRendererPriority(FontRendererPtr, int priority) where the existing FontFileRegisterRenderer interface in renderer.c is an alias for FFRRP with priority set to 0. Priority is an integer (positive or negative), and renderers with higher priority override renderers of lower priority. The Type 1 renderer would register with negative priority for both PFA and CID; in the absence of another CID renderer, it would render CID fonts, but PFA fonts would be handled by FreeType. FreeType would register with default priority for both PFA and TTF. X-TT would register with positivie priority for TTF. In a configuration in which all renderers are linked in, X-TT would handle TTF, FreeType would handle PFA, and Type 1 would handle CID. In a default configuration (no X-TT), both PFA and TTF are handled by FreeType. The advantage of that is that there are no new configuration mechanisms -- we simply leverage off the existing module loader. It's also easily extensible -- I expect to implement bitmap support in the FreeType backend after 4.3.0, and then you'll want the existing bitmap renderers to override FreeType if they're linked in. The downside is that it's not completely flexible, not allowing for example to have TTF support using FreeType while using Type 1 for PFA. I don't think anyone cares. DD> Also, I'd really like to see some resolution to the separate "FreeType" DD> and "X-TT" backends for TrueType fonts. As it is now, if someone chooses DD> "X-TT", they will still need the old Type1 backend for Type1 fonts DD> regardless of other considerations. Is it still not possible to resolve DD> the issues that led to two TrueType backends in the first place? Here's my personal perception. X-TT contains support for embedded bitmaps, which FreeType 1 didn't have. The new FreeType backend fully supports embedded bitmaps. X-TT also contains a number of features such as fake bolding and automagic slanting, collectively known as TTCap. These should be handled at the toolkit level in my opinion, and at any rate implementing new features in the core fonts system at this point is pretty much pointless. Still, users of X-TT have become accustomed to these features being made available at the server level, and would probably not accept them being taken away. I shall not implement the said features in FreeType, which I want to remain a small and clean piece of code. I shall also not integrate myself the (existing) patches that implement TTCap in the FreeType backend. If there is a person interested in doing that, I'll be glad to help -- but only if said person commits to maintaining the code for the indefinite future. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
PdV> I allready checked the freetype lists, and came to the conclusion PdV> that appart from a short discussion in february nothing is being PdV> done about pcf files for that memory reasons. http://www.xfree86.org/pipermail/fonts/2002-August/002019.html Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]FreeType 2 and gzipped font files
A first draft of a patch to allow FreeType 2 (current CVS) to read gzipped font files is available from http://www.pps.jussieu.fr/~jch/software/files/freetype2-gzip-20021019.patch.gz This patch works by keeping in memory the part of the uncompressed font file that has already been seen. The weak point is that compressed files are detected by filename extension; a cleaner solution would be to have the stock stream implementations invoke it when they detect the signature of a gzipped file. I didn't try to make it optional. Feel free to include a suitably modified version of this patch in FreeType if you find it suitable. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fontconfig + patched qt-3.0.5 doesn't allow bitmap fixed font
> In article <[EMAIL PROTECTED]>, Paul de Vrieze ><[EMAIL PROTECTED]> writes: PdV> I allready found the problem. The problem is the fact that the PdV> fixed font is not found. This is because all my pcf fonts are PdV> gzipped by default. For some reason fontconfig doesn't recognize PdV> them in this case. I will check whether I can come up with some PdV> patch for this. The problem is indeed at the FreeType level. When I have some time, I'll implement a decompressing filter for FreeType. It will use petabytes of memory, but will provide a short-term solution for people with petabytes of memory. The long-term solution is to dump the PCF format. This won't happen in time for 4.3.0. (Not to imply that the former will.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]A problem on using fonttootf problem
JL> I have recently trying to use the fonttootf to convert a bdf JL> font into otf. Please note that fonttotf is in an early alpha stage; it is not meant to be useful right now. I suggest that you should use pfaedit rather than fonttootf for the time being. JL> First, the bdf font is encoding in Big5 (to be exact the JL> encoding should be Big5-HKSCS). The current version of fonttootf requires Unicode-encoded fonts. Being able to use fonts in legacy encodings is a planned feature for future versions. JL> I use gdb to take a look and found that, the cause is the JL> absent of a 'FAMILY_NAME' so freetype just set the JL> face->family_name to 0 and the when " full_name = JL> malloc(strlen(face->family_name) + 1); " occurs inside read.c:81 JL> of the fontofotf, it bombs. Noted, thanks for the report. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]X server crashes when looping on all fonts
Hello, nice to hear from you again. NP> The problem is an optimization -- the X server doesn't load a font NP> until an app asks for information that can't be gotten from the NP> XLFD list (xlsfonts doesn't crash the server). Exactly. NP> What's more, the server doesn't unload fonts after you're done with them, NP> on the assumption that you'll need them later. That's not true. The memory is freed upon XFreeFont. NP> If it's not a bug, then exactly what is the way/API for looping on all NP> fonts in the system to get the info we need ? There is widespread consensus (among at least five people) that the current X11 font API is obsolete, and should not be used in new applications. The fact that you feel the need to loop accross all fonts at startup simply shows that the needs of GNUstep go beyond what the core fonts API provides. I think you should consider using client-side fonts, the RENDER extension, and the fontconfig/Xft2 API. Please see Keith's masterwork of propaganda on http://fontconfig.org/ Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale
MH> Yeah, there are many different 'variants' of ttmkfdir floating MH> around. [...] None of them are really superior for all purposes MH> unfortunately. In case you made any notes, I'm highly interested. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale
YS> You can try Red Hat 7.3's ttmkfdir which is included in XFree86, In RedHat's packaging of XFree86, not in XFree86's distribution. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ttmkfdir and mkfontscale
>> So, it means that, mkfontscale can do the job for my fonts, for my >> X Server, whatever it font file type and whatever the font module >> (freetype/type1/xtt)?? AK> Yes. Beware, though: mkfontscale is beta code. Please do drop me a note if you can get it to behave weirdly. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Bitmap-only TrueType files
JS> FWIW, I've tried to install several bitmap-only TTFs (gen. by JS> fonttootf) including three of them you made from GNU unifont into Fonts JS> folder of Windows 2k. Win2k refused to install them complaining that JS> they are invalid. Thanks; I have already been made aware of the problem. I suspect that I'm generating wrong checksums (neither FreeType nor pfaedit check them). Unfortunately, I'm out of hacking time right now, so if anyone wants to take over for now, go for it. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Bitmap-only TrueType files
KP> http://developer.apple.com/fonts/TTRefMan/RM06/Chap6head.html: KP> "TrueType fonts which have no outline data but consist of bitmaps KP> only should not have a 'head' table. They should use the KP> byte-by-byte identical 'bhed' table instead. The Mac OS uses the KP> presence of a 'bhed' to signal the fact that a font has no KP> outlines." What was that quotation by Tanenbaum again? There are three standards for TTFs: Apple's TTF spec, which you're quoting, Microsoft's TTF spec, and the Adobe-Microsoft OpenType spec. Embedded bitmaps are treated differently by the Apple and Microsoft specs, and I'm trying to follow Microsoft in fonttootf. In particular, I'm using an EBDT table rather than a bdat table. The OpenType spec does speak about bitmap-only fonts, although too vaguely to be of much guidance. I don't see any good reason to switch to following Apple, but have no a priori objection against doing so. I don't think it matters much, though; whichever spec we decide to follow, we'll need to modify FreeType to deal with bitmap-only TTFs. (I've tried to bribe Zappa-Nardelli last week-end; he wouldn't even accept a coffee. Could somebody be so kind as to buy Lembert a pint or two?) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] Fonttootf: first cut of a BDF->TTF converter available
VP> | Here's a summary of font sizes: VP> | (1) (2) (3) VP> | .pcf.pcf.gz pfaedit fonttootf fonttotf -c VP> | 8x13-L1.pcf 19572 4579 6908 40124032 VP> | 8x13.pcf41066057158 54044 52244 VP> | helvR14.pcf 7180413901 15780 15796 VP> | 9x18.pcf + 18x18ja.pcf77976 + 580901 796464 917620 VP> | VP> Do you have ani ideas why PfaEdit produces slightly better results VP> than your conversion tool? Read the table again. It's the other way around. Juliusz ___ 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
[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
[Fonts]Another bug in the BDF backend
Take 8x13.bdf, and look at the strikes exported by current Freetype CVS; there is a single strike of size 8x13. The PCF backend correctly exports this strike as 13x13. Recall that the size of a strike is in pixels per em; thus, for square pixels, the X and Y dimensions should be the same. The size of a strike has no relation with the strike's bounding box. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]FreeType bug report
OT> I'm pretty sure Microsoft ships a number of .ttf files with only OT> bitmaps and no outlines with Windows... Interesting. Which ones? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]FreeType bug report
PS> what will happen if one of such programs tries to use a bitmap PS> only font for displaying at a size for xhich there are no bitmaps PS> embedded ? It will get sixty-odd thousand blank glyphs. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Legacy software and bitmap-only snfts [was: FreeType bug report]
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). 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
[Fonts]FreeType bug report
Hello, Thanks a lot for the previous fix, I'll try it out tonight. I'm currently exploring the possibility of moving XFree86 from the PCF format to the sfnt format for bitmap fonts. I've encountered a number of minor bugs in FreeType 2.1.2 that prevent me from using such bitmap-only sfnts. 1. FreeType crashes at ttgload.c:103 if hhea->number_Of_HMetrics is 0. The problem is with k, which is assumed to be at least 1. 2. FreeType refuses to get an sbit that has a glyph index beyond maxp->numGlyphs. Note that the OpenType spec explicitly allows a font to have no scalable glyphs, although it warns against legacy rasterisers not being able to process such fonts. 3. FreeType refuses to load a font that has no loca or glyph tables. See the above note. For me, point 1 is not important (I've decided to generate a single htmx entry), but I think that any crash of FreeType is a severe bug. Point 2 is important, as it won't do to generate loca entries for all glyphs: such a font is too difficult to distinguish from a bona fide scalable font, and I want to generate a single loca entry (for .notdef). As to point 3, I don't care much about it; still, it might be handy to generate fonts with no loca/glyf tables in order to prevent legacy software from mistaking them for scalable fonts. No rush, but do tell me what you've decided to do about the above. Thanks, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
JC> I'll be posting the pfaedit generated ttfs later tonight. Never mind, I've worked out why I wasn't able to do it myself. Interestingly, pfaedit does generate blank scalable glyphs and scalable metrics for all glyphs in a bitmap-only font. On the one hand, this makes the fonts usable with current versions of FreeType (which will refuse to check for an sbit that is beyond maxp.numGlyphs -- a bug IMHO). On the other hand, this makes such fonts undistingui- shable from /bona fide/ scalable fonts. Did you know that the French code of typography does allow an em dash to appear at the beginning of a line? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Buggy metrics with FreeType 2 and BDF or PCF fonts?
Hi,
I'm attaching a little test program that you should run on 8x13.bdf
and 8x13.pcf. Please notice the (x, y) couple printed for every
glyph, which are, respectively,
face->glyph->metrics.horiBearingX and
face->glyph->metrics.horiBearingY.
The 8x13 font has a bounding box of (0, -2) through (8, 11). Thus, I
believe that the correct values should be (0, 704). However, I'm
getting
(0, -128) for the BDF version; and
(512, 704) for PCF version.
Can anyone confirm this bug, or tell me what I'm doing wrong?
Thanks,
Juliusz
--
#include
#include
#include "freetype/freetype.h"
FT_Library ft_library;
int
main(int argc, char **argv)
{
int rc, index, code, x, y;
FT_Face face;
if(argc != 2)
exit(1);
rc = FT_Init_FreeType(&ft_library);
if(rc != 0) {
fprintf(stderr, "Couldn't init library: %d.\n", rc);
return 1;
}
rc = FT_New_Face(ft_library, argv[1], 0, &face);
if(rc != 0) {
fprintf(stderr, "Couldn't make new face: %d.\n", rc);
return 1;
}
rc = FT_Set_Pixel_Sizes(face, 13, 13);
if(rc != 0) {
fprintf(stderr, "Couldn't select size: %d.\n", rc);
return 1;
}
rc = FT_Select_Charmap(face, ft_encoding_unicode);
if(rc != 0) {
fprintf(stderr, "Couldn't select charmap: %d.\n", rc);
return 1;
}
for(code = 0; code < 0x; code++) {
index = FT_Get_Char_Index(face, code);
if(code != 0 && index <= 0)
continue;
rc = FT_Load_Glyph(face, index,
FT_LOAD_RENDER | FT_LOAD_MONOCHROME);
if(rc != 0) {
printf("Couldn't load glyph %d(%d): %d.\n\n",
code, index, rc);
continue;
}
printf("%d(%d): %d x %d (%d, %d)\n",
code, index,
face->glyph->bitmap.width, face->glyph->bitmap.rows,
face->glyph->metrics.horiBearingX,
face->glyph->metrics.horiBearingY);
for(y = 0; y < face->glyph->bitmap.rows; y++) {
for(x = 0; x < face->glyph->bitmap.width; x++) {
if((face->glyph->bitmap.buffer[y * face->glyph->bitmap.pitch +
x / 8] &
1 << (7 - x % 8)) != 0)
printf("*");
else
printf(" ");
}
printf("\n");
}
printf("\n");
}
return 0;
}
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]GPL font
D> From what they tell me it seems that the font renderer is not D> recognizing the embedded bitmaps and is reverting to the hinting D> instructions (which I didn't spend much time on).. Is this true? This is true in XFree86 4.2.0. It will hopefully no longer be true in 4.3.0. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Juliusz> I'm getting slightly worse results here: JC> 1/6th larger was for the comparison of all of the utopia strikes in a JC> single EBDT style font vs the ten 10646-1 pcf.gz files. I'm still not getting anything close to what you claim: wc -c luRS??.pcf : 509624 wc -c luRS??.pcf.gz : 99842 luR.ttf : 144404 I may be doing something wrong like failing to do the right cropping. It's difficult to check because the generated TTFs are not quite complete yet, so you cannot look at them with the available tools. JC> Is there any benefit to a bdat table over a EPDT table? pfaedit also JC> shows sbit as an option, The TTF spec doesn't document either. I'll have a look in the OTF spec and the GX documentation (if I can still find it). Do you know what is implemented by FreeType 2? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
CP> OpenOffice.org will fall flat with this kind of TrueType fonts. No, it won't. They are perfectly good TTF fonts. A rasteriser that is not aware of sbits will simply see them as fonts with only one glyph (.notdef). CP> We assume TTFs to be printable and scalable. So it would be nice CP> to get a pointer to these new fonts as soon as you have somthing CP> ready to test with. I suggest you should add the following logic. When opening a TTF, check the number of entries in the loca table; if it is one or less, ignore the font. (Note that that's the loca table, not the cmap table, which does apply to sbits, nor the hmtx table, the treatment of which hasn't been settled yet.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
JC> I just tried importing each of the utopia bdfs into pfaedit and JC> generating a ttf. The 18pt and 24pt 75dpi bdfs could not be imported JC> w/o overwriting 100dpi versions because they had the same PIXEL_SIZE. JC> I think this is a limitation of pfaedit rather than the ttf/otf format. It's a limitation of the font format. A strike is identified by two values, which are the horizontal and vertical em sizes in pixels. (The two may be different if pixels are not square.) JC> The resulting ttf worked fine. Could you tell me whether the hmtx contains a full set of metrics, or only metrics for .notdef? If you don't know how to do that, could you please send me the output of hexdump -C < foo.ttf | head -n 20 JC> OTOH, the pfaedit-generated ttf (or otf) was about 1/6 larger than the JC> total of the gzip(1)ed pcf files per wc -c, but only 8k larger per du. I'm getting slightly worse results here: 8x13.pcf: 304676 8x13.pcf.gz: 56523 8x13.ttf: 73644 This should be taken with a grain of salt, as I'm generating a trivial hmtx table, trusting the rasteriser to do the right thing with EBDT. The font will be slightly larger if I decide to generate a full hmtx. On the other hand, this will get smaller when I implement (1) glyph sharing (encoding multiple identical glyphs only once), (2) composites detection (encoding a composite glyph as a reference to its components), (3) segments with uniform metrics and (4) bit-padded (as opposed to byte-padded) bitmaps. Juliusz P.S. And no, it's not ready for distribution. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
KP> That's a nice addition as well. I don't really care if we combine KP> multiple faces into a single .ttc file; I think he meant combining multiple sizes into a single TTF. Recall that TTF/OTF is a scalable format, and may contain sbits for multiple sizes (``strokes'' in OTF parlance). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
KP> Good. Now to generate something that can write TTF files with only sbit KP> entries. Keith, the subtleness of your hints is not improving ;-) I actually have started working on such a beast (a couple of months ago), but then other things came up, and it's not ready for sharing. I'm a wee bit busy right now (or else I wouldn't be at the computer at this time -- it's 11pm over here). And when I'm done with Real Work, my priority is to fix the known bug in the FreeType 2 backend so we can get rid of FreeType 1. (Thanks to the friendly folks at SuSE, by the way, for providing me with a useful bug report.) I estimate the remaining work at one afternoon, but I really don't know when I'll have said afternoon to devote to it; probably not before ten days or so. If anyone wants to take over before then, drop me a note, and I'll pass you what I have. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
JC> The resultant ttfs should also, IMO, include sufficient hints so that JC> mkfontdir can generate fonts.dir entries from them exactly as it now JC> can from the bdf files. In fact, all of the properties from the bdf JC> files' STARTPROPERTIES section should be encoded into the ttf. Do we or don't we want to support non-standard font properties? JC> Or perhaps the current tables are sufficient to encode all of that JC> data. No, they aren't. There's no way to encode a foundry name that hasn't been standardised by Microsoft. There's also no way to encode the XLFD charset of a symbol font. Let alone non-standard properties, such as the various _DEC_* thingies that are present in some of the SI's fonts. KP> If anyone has experience writing TrueType font files, help KP> would be greatly appreciated in building something that can KP> create these new files. I looked at what can be done when we first discussed the idea. Fonts in that format cannot be compressed -- OTF is intrinsically a seekable format. On the other hand, sbits are a highly compact format, allowing among others sharing glyphs (even between different strokes) and bit-aligned rasters (Mac-style; Microsoft-style are byte-aligned). Additionally, it is possible to have a very compact format for composites (similar to the Type 1 seac operator); if anyone knows of a good algorithm for detecting such optimisations, I'm curious to hear you. I'm planning to modify mkfontscale to generate scalable entries only if outlines are present, and to generate non-scalable entries otherwise by checking what sbit strokes are included. JC> Alternatively, pfaedit ought to be able to do this right now, and JC> could be scripted to automate the task. AFAIK, pfaedit will only output sbits for glyphs that also have an outline. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
>> Please do not do that. It will make the life of developers miserable >> (would *you* think of asking about the user's locale upon receiving a >> bug report you cannot reproduce?). KP> But the alternative is to require custom configuration for every user -- KP> consider a system supporting both Japanese and Korean users, there cannot KP> be a single default 'sans' font which can optimally display both of these KP> languages. Using LC_CTYPE gives the system a chance to select the right KP> font without requiring customization. No; the alternative is to require every application developer to perform what you do at the library level at the application level. This way, a developer who hits the issue is already aware of internationalisation issues, and has a chance to work out what the problem is. I don't feel particularly strongly about this, though. KP> Even in western environments, it's easy to believe that the best font for KP> German users will be different from that for Czech users; the coverage of KP> preferred font for German might well be missing Z WITH CARON. You already know my opinion on the issue: applications should be able to fall back to different fonts upon encountering a glyph they cannot display. Heck, I actually wrote Cedilla just to demonstrate how that can be done! (Offtopic rant: but of course nobody is interested in such a low-tech solution, preferring instead to discuss the gasworks known as OpenType.) Juliusz P.S. http://www.pps.jussieu.fr/~jch/software/cedilla/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
BS> Any thoughts on what would be a good fallback if the document does BS> not specify a language group and the document encoding does not BS> give a hint (eg: Unicode)? At the application level, using the user's locale is reasonable IMHO. What I object to is doing that at the library level, where the application developer might not be aware of what's happening. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Question on xft font library.
>> > 1. It seems that XFT is so good, so what's about the conventional fonts >> > module inside X, like the xtt, freetype, type1, etc... >> The X server can still provide fonts for applications not yet ported to >> Xft. These modules will be useful as long as you have some older >> applications left around. > Do you mean that, these two module is stable enough, and no active > development works is carried on these? I am the maintainer of the freetype module, and I try to encourage people to move over to using Xft for new applications, and port existing applications to Xft whenever reasonable. Now that Xft doesn't have particular server-side requirements, there is no reason whatsoever to avoid using it. The freetype module is being actively maintained, and there is a new version that will hopefully get into XFree86 4.3.0. However, I shall not add any new features to it; in particular, the ``freetype'' module will never support TTCap. If you feel that you need the features of TTCap, then I believe that you should be using Xft rather than the core fonts system. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Using current locale in font selection
KP> Much as I hate the C locale model, I'm wondering if I shouldn't use the KP> current locale as a language hint where applications don't provide KP> explicit language information when selecting fonts. Please do not do that. It will make the life of developers miserable (would *you* think of asking about the user's locale upon receiving a bug report you cannot reproduce?). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
