Re: [Fonts]Crash server with xfontsel
xlsfonts -u -fn blah ^^ Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
How does Pablo's suggestion sound to you? Would it be useful? KP In principle, it sounds fine. Instead of creating a new configuration KP mechanism, we should simply use the one underlying Xft. That would have KP the benefit of also supporting the new font name syntax (as well as XLFD). Can you provide me with some code to produce a list of pairs of (XLFD, filename) out of an Xft config file? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Keith Packard [EMAIL PROTECTED]: Can you provide me with some code to produce a list of pairs of (XLFD, filename) out of an Xft config file? KP Hmm. I can give you everything except average width; for that field, I'd KP have to rasterize the appropriate subset of the font and compute it. KP Certainly for the scalable names, it's easy enough. Good, it's only that that I need. Following Pablo's idea, I'm thinking of introducing a new kind of FPE that you point at an Xft config file and that pushes the fonts to the existing scalable backends. Can I distinguish -m- from -c-? KP You can play with the existing XftListFonts interface if you want to see KP how it might work. Hmm... I'm not sure we want to link Xft server-side. KP Figuring out the list of supported encodings will require a small amount of KP additional work; First draft does Latin-1. Then we'll see. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Proposal for XML-based font configuration
Keith Packard: KP I have an opportunity to redefine the configuration language [...] KP I've decided to give XML a try and see how it looks; [...] Keith, please, don't. The former configuration language was human-readable and human- writeable. This is not the case of your new XML thingie. While there do exist human beings who can read XML on sight, all known occurences are Ph.D. students and lose this knack as soon as they submit. Writing a parser for a well-designed language is a trivial exercice, whether you use yacc/lex or write it by hand (as Real Men do). I don't think that giving up the elegance of a human-readable language for the perceived convenience of being able to use off-the-shelf tools is a sane trade-off. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Outlines to borrow
RP I and my team are developing a set of Persian OpenType fonts, to RP contribute to XFree86 (and other projects). Can someone tell me that from RP which fonts may I steal (read borrow) the glyph outlines for ASCII RP characters and other punctuations (open double quotes, etc)? The Bitstream fonts (Charter and friends): probably yes, but I don't remember for sure. IBM Courier and Adobe Utopia: probably not, but does anybody actually know? Luxi/Lucidux: definitely not. In addition, you may want to check the GhostScript fonts from URW++ (in version 6.0 or later) which come under the GPL -- which will make your font impossible (or unlikely?) to be included in XFree86. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]More on CID-keyed JP fonts
EvdP What is the (now obsolete) Unicode mapping of JIS to UCS? Are you EvdP talking about unicode.org's JIS X 0208-Unicode mapping? Yep. IIRC, it's been obsoleted, deprecated, or whatever. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Special Characters
MK An X11 client does not see a Type1 font directly. It just sees an X11 MK font, and that can be up to 2^16 glyphs large. XFree86 can recode a MK Type1 font in any encoding into an X11 font in many encodings, including MK CP1252 and ISO10646-1. Yes, except that the current code limits X11 fonts deried from Type 1 and Speedo fonts to 256 codepoints. (The data structures would need to be changed in order to efficiently deal with larger codepoint spaces.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Freetype] Re: [Fonts]FreeType 2 backend for XFree86
KP I believe freetype should be treated as a system library, much as KP libc is today. This could include building a thunk layer like the KP current xf86_ansic.h to ensure portability. You're absolutely right, as usual. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
BS Defining common names like ''read'' always leads to problems BS when using multiple packages. BS Why doesn't XFree86 follow common C protocol and use uppercase? BS Better yet, why not use a name like XF86_READ to avoid conflicts BS on such common names? The goal being to use common source code both in the X server (when using the wrappers) and outside it, it would be rather pointless to use ``common C protocol'', wouldn't it? The symbol name is xf86_read; it is the choice of the module author whether to include xf86_libc and use xf86_read directly, or whether to include xf86_ansic and have a nice define from read to xf86_read. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
My wrong. Sorry for that. WL is in the middle of the ftsystem.c instead of the beginning. For some reason, I was convinced that malloc needs to be defined (by the #include), then undefined, then defined again. I'm glad it's not needed. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Freetype] FreeType 2 changes required for XFree86
Hi Antoine! So nice to hear from you. BS Defining common names like ''read'' always leads to problems BS when using multiple packages. BS Why doesn't XFree86 follow common C protocol and use uppercase? The goal being to use common source code both in the X server (when using the wrappers) and outside it, it would be rather pointless to use ``common C protocol'', wouldn't it? AL I am not sure you (both Brian and Juliusz) will have a similar dispute AL about tolower or malloc, would you? We're not having a dispute. A dispute is a form of exchange, and in this case Brian is obviously not listening. Brian is absolutely right that all-caps names should be used for processor defines in the ordinary case, and XFree86 code follows this convention religiously. The definitions done in xf86_ansic.h are in a completely different situation, and Brian's received wisdom does not apply to them. In XFree86 modules that include xf86_ansic.h, a number of libc symbols (standard or not, that's not the point) are redirected to their cross-platform xf86_* equivalents. Due to the lack of a module system in C, this redirection is done at the preprocessor level: #define read(x, y, z) xf86_read(x, y, z) #define tolower(x) xf86_tolower(x) ... etc ... Obviously, the fact that it's the very names used by libc that are redefined is the very essence of the hack in question. Suggesting that we redefine some other names instead is missing the point althegither. I hope this clarifies matters, and I suggest that we should close this completely pointless discussion. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]New version of FreeType 2 backend
You will find a new version of the FreeType 2 backend on http://www.pps.jussieu.fr/~jch/software/files/ New features: - generates the same set of properties as the FreeType 1 version; - support for the X11R6 XLFD extensions. Still to do: - support for non-AGL Type 1 fonts (typically symbol fonts); - support for CIDFOnts. At the same place, you will find a minor patch for the mkfontscale utility (submitted as 5214). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New version of FreeType 2 backend
JC Unfortunately, this is a no-go. Although xlsfonts(1x) works JC perfectly, any attempt to actually render a scalable font via the new JC backend dies with a segfault. Curious... I don't think there are any binary incompatibilities visible to drivers between 4.2.0 and current HEAD. Please do try a homogeneous recompile and tell me aboput your findings. JC And also against HEAD if I JC can figure out a way to do so w/o killing the current install. I don't have my sources handy, so I'm citing from memory. Please double-check the following incantations: #define ProjectRoot /usr/local/X11R6 #define NothingOutsideProjectRoot YES Note that if you do this and also define BuildServersOnly, you'll need to softlink your fonts and security directories from /usr/X11R6 to /usr/local/X11R6. (Actually I don't bother about security and just live with the warnings when testing the /usr/local installation.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New version of FreeType 2 backend
IM I found a typo in ftfuncs.c. This cause segv and to crash IM X server. Thanks a lot. I'll make this fix available with the source, and integrate it in the next version. JC It complains that it could not find encoding ascii-0 That's a ttmkfdir weirdness. The FreeType 1 backend did behave in the same manner (falling back to ISO 8859-1), but didn't complain unless compiled with debugging. I've decided to be more verbose about errors in this version. JC cff otf fonts still will not load. I do not have access to any OpenType/CFF fonts. If you can point me to some that are available on the web, I'll see what the problem is. JC I've now also tested with the backend loaded into the x server. Type1 JC fonts seem to have incorrect bounding boxes, per xfd(1x) output. You mean incorrect glyph metrics, or incorrect font-level metrics? I know of at least one problem: I transform the Type 1 font-level metrics by 1000*I rather than by the font's matrix as should be. You'll get incorrect font-level metrics for any font that uses a non-standard font matrix. There are probably other problems: I've really done almost no testing yet. JC Would an fslsfonts output provide some help here? Thanks for the offer, but it's premature; if you still see issues with the next version (no schedule), we will want to discuss them. Thanks to both of you for the feedback, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New versions of mkfontscale and FreeType 2 backend
JC I'm running the new ft2 backend now for all scalled fonts. JC Most everything looks good so far. Great to know. JC Perhaps generalizing -adobe-fontspecific into -*-fontspecific JC would be reasonable? Fine. Although mkfontscale will still only generate `adobe-fontspecific'. JC I'm also having trouble adding /usr/lib/jdk1.3/jre/lib/fonts JC to the font path. Permissions? NFS authorisation? (The server runs as root, not as you.) I'll try to see if I can reproduce it. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New versions of mkfontscale and FreeType 2 backend
JC The average width error is still there for type1 fonts, but AFAICT JC it affects very few programs that one usually doesn't notice. According to David Turner, this may be a bug in FreeType 2.0.9 that was fixed in 2.1.0. I haven't had time to test his guess yet. (Keith, what about importing 2.1.0?) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New versions of mkfontscale and FreeType 2 backend
JC I jus realized that there is a significant difference with the new JC ft2 backend. I've lost underlining in mozilla. Please check the values of the UNDERLINE_POSITION and UNDERLINE_WIDTH properties (xlsfonts -ll -fn 'foo'). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New versions of mkfontscale and FreeType 2 backend
CC'd to Freetype.
Rui-Xiang Guo [EMAIL PROTECTED]:
RG - jisx0212.1190-0, big5.eten-0, gb2312.1980-0,
RG + jisx0212.1990-0, big5-0, gb2312.1980-0,
Okay, in next version. Thanks.
RG (I tested it with Arphic TTF which be distributed with most Linux
RG distributions and all *BSD.)
Hmm, there may be problems with this font; I'm told it has bugs.
Maybe the FreeType folks can comment?
RG It seems the problem of FT_Get_Char_Index() in checkEncoding().
RG -if(FT_Get_Char_Index(face, c) == 0) {
RG +if(face face-charmap) {
RG +ttcmap = ((TT_CharMap)face-charmap)-cmap;
RG +if(ttcmap-get_index)
RG +/* if(ttcmap-get_index(ttcmap, c) == 0)
RG +return 0; */
RG +return ttcmap-get_index(ttcmap, c);
Very curious. I'll try to understand what's going on.
RG 3) Besides that, I need to fix the spacing value 'p' to 'c' because the
RG value 'p' will cause delay in several seconds when start-up rxvt.
Again, that's a font bug; mkfontscale tries to work out which fonts
are proportional. On the other hand, it doesn't yet implement a
heuristic to distinguich monospaced (-m-) from charcell (-c-) fonts.
I guess a suitable heuristic would be to decalare all monospaced fonts
in East-Asian encodings to be charcell.
RG Would it be merged into next XFree snapshot?
I hope so.
Thanks,
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New versions of mkfontscale and FreeType 2 backend
JC With type1 fonts, the UNDERLINE_POSITION is O(PIXEL_SIZE/10). I JC presume the sign is then the problem. Thanks a lot for the debugging -- fix in next version. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Scaled bitmap fonts
KP Let's just rip the bitmap scaler out once and for all. If we do that (and I have no objection), we should encourage all distributions to provide scalable fonts for the Adobe base-14. The necessary font files are available with Ghostscript 6, and are already included in most distributions. Debian already makes them available to the X server. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Removing bitmap scaling code
Shall I remove the bitmap scaling code outright, or merely make it optional (defaulting to no)? I'm tempted to remove the code althegither, fontscale pollutes quite a bit of the fontfile code and is not something we want to maintain forever. Are there any objections? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]HP-Roman8 Problem
IY HP-ROMAN8 Dear Ian, XFree86 uses the ISO 8859-1 (``Latin-1'') character set for Western-European languages, which is derived from DEC Multilingual. For historical reasons, HP uses the HP ROMAN-8 character set. While it would be easy to add ROMAN-8 support to XFree86, XFree86 does not currently support the ROMAN-8 character set, which we believe to be obsolete. The simplest workaround would be to add aliases for ISO 8859-1 fonts to the ROMAN-8 names; please see the mkfontdir(1) manpage. You should be aware that doing this will break accented characgters. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New versions of mkfontscale and FreeType 2 backend
Thanks for the report and the suggestions. RG It looks better then I added this line by hand: RG MINGLIU.TTC -dynalab-MingLiU-medium-r-normal--0-0-0-0-m-0-big5-0 Yu Shao has just suggested to me the following heuristic for CJK fonts: an encoding is supported by the font if fewer than 2% of the glyphs are missing. I'm going to implement this scheme, and Big-5 encodings should be properly generated in the next version. RG The spacing value 'm' still will cause delay with rxvt. Don't know why. :) There's an optimisation (hack) for charcell (as opposed to monospaced) fonts in the FreeType backend. The delay you're seeing is what happens when we don't apply said hack. RG How about using os2-ulCodePageRange1 to lookup the font encoding RG for supporting modren Unicode encoded CJK fonts? I need to think about it some more. What if Microsoft comes up with Courier New Unicode? I'm more tempted to peek at the font's bounding box to determine if it's charcell. I'll need to check whether this gives good results. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]New version of mkfontscale
Version 20020524 of mkfontscale is available from http://www.pps.jussieu.fr/~jch/software/files/ Changes: - Implements ``fuzz'' value for large encodings (defaults to 1%); precise heuristics are still used for 8-bit fonts. - Implements simple heuristic for distinguishing charcell fonts; tested with Courier New (-m-) and Lucida Console (-c-), more testing is needed. - Empty names are now treated the same as missing, which may (or may not) work around some arguably incorrect fonts. - Changed big5.eten-0 to big5-0. Thanks to all who provided the feedback that led to the above improvements. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]New version of mkfontscale
JC precise heuristics Sorry for that. But then, I've heard people talk of ``elegant perl code''. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Ciach bitscale! [2nd attempt]
I've sent this already, but it was upheld for moderation due to file size. Sorry for not thinking about this earlier. I've put a patch that removes the bitmap scaling code on http://www.pps.jussieu.fr/~jch/software/private/no-bitmap-scale.patch I've only tested it with KDrive, but there's no good reason why it should break the XFree86 server. It probably breaks Xprt, though. I'd be glad to get some feedback before submitting it. If people object, I can always make a patch that makes the bitmap scaling optional but doesn't actually remove any code. Here's my suggested release notes entry: The support for scaling bitmap fonts is removed. The server's ability to scale bitmap fonts confuses both users and application developers. Many X installations are configured incorrectly, leading to the familiar ``ugly fonts'' syndrome. Recently, high-quality free scalable vector fonts have become widely available; a number of such fonts are included with XFree86, others can be found bundled with other software packages, notably Aladdin Ghostscript version 6.0 and later. Because of that, the ability to scale bitmap fonts is no longer needed, and has been removed from XFree86, leading to much simpler server configuration. Because of this change, you will need to remove any ``:unscaled'' attributes from your font path. Please check your XF86Config (or XF86Config-4) file for any lines of the form FontPath/usr/lib/X11/fonts/misc/:unscaled and remove the ``:unscaled'' part, e.g. FontPath/usr/lib/X11/fonts/misc/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Ciach bitscale! [2nd attempt]
KP I suspect we need to make the bitmap scaler optional; allow either
KP :scaled or :unscaled options on the font path elements and make
KP the default :unscaled.
Keith, I hate you. Okay, I'll do that.
KP I'd like to have a build-time option to get rid of the code for kdrive
KP servers,
Appended.
KP but disabled by default.
How do I read an XF86Config flag from a font backend?
KP An alternative that could work is to (optionally) advertise
KP scalable names but do nearest-size matching instead of bitmap
KP scaling;
Not difficult, the code is already there (when selecting a bitmap font
to scale); what bothers me is that we're adding code where should be
removing it.
Juliusz
Index: xc/lib/font/bitmap/bitscale.c
===
RCS file: /cvs/xc/lib/font/bitmap/bitscale.c,v
retrieving revision 3.22
diff -c -r3.22 bitscale.c
*** xc/lib/font/bitmap/bitscale.c 2001/12/14 19:56:46 3.22
--- xc/lib/font/bitmap/bitscale.c 2002/05/31 17:26:35
***
*** 49,54
--- 49,80
#define MAX(a,b)(((a)(b)) ? a : b)
#endif
+ #ifdef NO_BITMAP_SCALER
+
+ /* ARGSUSED */
+ int
+ BitmapOpenScalable (FontPathElementPtr fpe,
+ FontPtr *pFont,
+ int flags,
+ FontEntryPtr entry,
+ char *fileName,
+ FontScalablePtr vals,
+ fsBitmapFormat format,
+ fsBitmapFormatMask fmask,
+ FontPtr non_cachable_font)
+ {
+ return BadFontName;
+ }
+
+ /* ARGSUSED */
+ static void
+ bitmapUnloadScalable (FontPtr pFont)
+ {
+ return BadFontName;
+ }
+
+ #else
+
/* Should get this from elsewhere */
extern int serverGeneration;
***
*** 1952,1954
--- 1978,1982
xfree (pFont-fontPrivate);
DestroyFontRec (pFont);
}
+
+ #endif
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Disable font scaling and make Keith happy too [patch]
Hello,
Following the objections to my previous patch, here's a version that
sports three build-time and two runtime mechanisms for configuring the
bitmap scaling code in or out. Say wow.
By default, bitmap scaling is compiled in; naked FPEs do not scale
bitmaps, the ``:scaled'' attribute can be used to enable bitmap
scaling. I understand this is the behaviour that Keith and Mike
condone.
The bitmap scaler can be compiled out with -DNO_BITMAP_SCALER; in
order to remove the ``:foo'' parsing code, don't -DFONTDIRATTRIB.
Both flags are controlled by the NoBitmapScaler Imake flag.
At runtime, the default for naked FPEs is controlled by the global
variable ``defaultScaleBitmaps''. This variable is initialised to
DEFAULT_SCALE_BITMAPS, which defaults to false. There is currently no
way to change its value at runtime other than by using a debugger. If
defaultScaleBitmaps is true, it can be overridden by using
``:unscaled''.
(Somebody could write an extension to control the value of
defaultScaleBitmaps at runtime. After all, that's no more ridiculous
than the FontCache extension.)
Juliusz
? xc/lib/font/fontfile/DONE
? xc/lib/font/fontfile/Makefile
Index: xc/lib/font/fontfile/Imakefile
===
RCS file: /cvs/xc/lib/font/fontfile/Imakefile,v
retrieving revision 3.21
diff -c -r3.21 Imakefile
*** xc/lib/font/fontfile/Imakefile 2002/02/13 21:32:48 3.21
--- xc/lib/font/fontfile/Imakefile 2002/06/03 06:32:02
***
*** 49,58
GZIP_DEFS = -DX_GZIP_FONT_COMPRESSION
#endif
ATTRIBDEFS = -DFONTDIRATTRIB
FONTENCDEFS = -DFONT_ENCODINGS_DIRECTORY=\$(FONTDIR)/encodings/encodings.dir\
! DEFINES = StrcasecmpDefines $(ATTRIBDEFS) \
$(SPEEDO_DEFINES) $(TYPE1_DEFINES) $(CID_DEFINES) \
$(FREETYPE_DEFINES) $(XTRUETYPE_DEFINES) $(FONTENCDEFS) \
$(GZIP_DEFS)
--- 49,69
GZIP_DEFS = -DX_GZIP_FONT_COMPRESSION
#endif
+ #if NoBitmapScaler
+ #if ForceFontDirAttrib
ATTRIBDEFS = -DFONTDIRATTRIB
+ #endif
+ #else
+ ATTRIBDEFS = -DFONTDIRATTRIB
+ #endif
+
+ #if NoBitmapScaler
+ BITSCALE_DEFS = -DNO_BITMAP_SCALER
+ #endif
+
FONTENCDEFS = -DFONT_ENCODINGS_DIRECTORY=\$(FONTDIR)/encodings/encodings.dir\
! DEFINES = StrcasecmpDefines $(ATTRIBDEFS) $(BITSCALE_DEFS)\
$(SPEEDO_DEFINES) $(TYPE1_DEFINES) $(CID_DEFINES) \
$(FREETYPE_DEFINES) $(XTRUETYPE_DEFINES) $(FONTENCDEFS) \
$(GZIP_DEFS)
Index: xc/lib/font/fontfile/fontdir.c
===
RCS file: /cvs/xc/lib/font/fontfile/fontdir.c,v
retrieving revision 3.18
diff -c -r3.18 fontdir.c
*** xc/lib/font/fontfile/fontdir.c 2001/12/14 19:56:51 3.18
--- xc/lib/font/fontfile/fontdir.c 2002/06/03 06:32:02
***
*** 34,39
--- 34,49
#includefntfilst.h
#includeX11/keysym.h
+ /* Whether to scale bitmap fonts when neither :unscaled nor :scaled
+ * are present. If a different default is desired, the command-line
+ * parsing code should set this. */
+
+ #ifndef DEFAULT_SCALE_BITMAPS
+ #define DEFAULT_SCALE_BITMAPS 0
+ #endif
+
+ int defaultScaleBitmaps = DEFAULT_SCALE_BITMAPS;
+
Bool
FontFileInitTable (FontTablePtr table, int size)
{
***
*** 654,681
(vals.values_supplied PIXELSIZE_MASK) != PIXELSIZE_ARRAY
(vals.values_supplied POINTSIZE_MASK) != POINTSIZE_ARRAY
!(vals.values_supplied ENHANCEMENT_SPECIFY_MASK);
#ifdef FONTDIRATTRIB
#define UNSCALED_ATTRIB unscaled
! /* For scalable fonts, check if the unscaled attribute is present */
! if (isscale dir-attributes dir-attributes[0] == ':') {
! char *ptr1 = dir-attributes + 1;
! char *ptr2;
! int length;
! int uslength = strlen(UNSCALED_ATTRIB);
!
! do {
! ptr2 = strchr(ptr1, ':');
! if (ptr2)
! length = ptr2 - ptr1;
! else
! length = dir-attributes + strlen(dir-attributes) - ptr1;
! if (length == uslength !strncmp(ptr1, UNSCALED_ATTRIB, uslength))
! isscale = FALSE;
! if (ptr2)
! ptr1 = ptr2 + 1;
! } while (ptr2);
! }
#endif
if (!isscale || (vals.values_supplied SIZE_SPECIFY_MASK))
{
/* If the fontname says it is nonScalable, make sure that the
--- 664,710
(vals.values_supplied PIXELSIZE_MASK) != PIXELSIZE_ARRAY
(vals.values_supplied POINTSIZE_MASK) != POINTSIZE_ARRAY
!(vals.values_supplied ENHANCEMENT_SPECIFY_MASK);
+
+ if (isscale) {
+ int surelyScale = FALSE;
+
#ifdef FONTDIRATTRIB
#define UNSCALED_ATTRIB unscaled
! #define SCALED_ATTRIB scaled
! /* For scalable fonts, check if the unscaled or scaled attribute
! * is present */
!
!
Re: [Fonts]Re: Saving memory in fontconfig
KP This shows sub-linear growth in memory vs the number of fonts; I KP need to try even larger sets to get a better sense of the actual KP function here. Should I take this as meaning that the bitmaps dominate over the bureaucratic overhead, right? If so, could you try with 128-codepoint pages? A significant part of Unicode is organised into 128-codepoint ranges. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]xfd
SD Does xfd have to be Xlib aware of the new encoding No. Xfd is encoding-agnostic. What format is the font in and are you using Sun's X server? Xsun does weird things with scalable fonts, and I'm not sure that this list is the right place to ask about Xsun. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]ft2 backend pixelsize vs bitmap pixelsize
JC In doing so, I discovered that fixed, aka: JC -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 JC has an ASCENT of 11 and DESCENT of 2 (totalling 13), whereas JC -bh-Luxi Mono-medium-r-normal--[9.75 0 0 13]-0-75-75-m-0-iso8859-1 JC while intended to match those metrics ends up with an ASCENT of 13 and JC DESCENT of 3. Please, not that question. In short, the font's point size, ascent and descent are three random values that depend on the font, the font technology, and even the individual foundry or font designer. No particular relationship between the three values should be expected. As you probably know, a molten lead fo(u)nt is a collection of blocks of lead with glyphs embossed at the top. In order for the type to align neatly in the galley, all the blocks in a single font have the same dimension in the direction parellel to the paper but orthogonal to the direction of writing; this dimension is known as the font's /point size/, or /em size/, or /quad size/. Obviously, it is physically impossible to typeset two lines of 10 pt Garamond less than 10 pt away; on the other hand, nothing prevents you from typesetting them 12 pt away by inserting 2 pt wide strips of lead; you then speak of typesetting 10 pt Garamond with 2 pt /leading/, or sometimes 10/12 pt Garamond. Thus, with molten-lead fonts, for a given typeface, the choice of the point size is merely a technical decision, and very similar fonts can have different point sizes depending on the technical tradeoffs made by the foundry. While there have been attempts to rationalise this nowadays obsolete notion (most notably by Knuth), it has carried over to digital fonts. Nothing should be expected from the point size except that within a single family produced by a single foundry the size of glyphs should be roughly correlated with the point size. What about the font's ascent and descent? As opposed to a glyph's ascent and descent, which are well-defined notions, these have no meaning at all. They are arbitrary values that are produced mostly at random by the various font backends. In the case of the TrueType fonts in the FT1 or FT2 backends, they are merely scaled versions of values that are found in the font file -- randomly chosen by the font designer. For Type 1 fonts produced by FT2, they are scaled versions of the font's bounding box (and thus depend on the font's glyph coverage, but not the encoding). In the case of the Type 1 backend, they are the max of the scaled values of the bounding boxes of the glyphs present in the encoding (and thus depend on the encoding). In the case of bitmap fonts, they are just taken from the font file. The only reasonable use of the font's point size is to allow the (human) user to specify it. The only reasonable interpretation of the font's ascent and descent is to use them as a user-tweakable default for the positionment of baselines. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]FreeType 2 backend submitted for inclusion in CVS
Dear all, I've just submitted the latest version of the FreeType 2 backend and the latest mkfontscale for inclusion into CVS. For XFree86 members, they're available as patches 5305 through 5308; they are no longer available from my web page. Many thanks to all who helped with development and testing, and to the FreeType authors for their willingness to uglify their code in order to make my life easier. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Fix -c- spacing in FreeType 2 backend
Would you be so kind as to test the attached? (Not submitted, waiting
for confirmation that it actually works.)
Thanks,
Juliusz
P.S. Anybody got clean code to do a 1bpp unaligned blit?
*** /tmp/xc/lib/font/FreeType/ftfuncs.c Sat Jun 8 20:03:07 2002
--- xc/lib/font/FreeType/ftfuncs.c Thu Jun 20 19:05:11 2002
***
*** 73,78
--- 73,80
static FTFacePtr faceTable[NUMFACEBUCKETS];
+ #define MAX(_x, _y) ((_x)=(_y)?(_x):(_y))
+
static unsigned
hash(char *string)
{
***
*** 565,574
char *raster = NULL;
FT_Size_Metrics smetrics;
FT_Glyph_Metrics *metrics;
! int wd, ht, bpr; /* width, height, bytes per row */
int leftSideBearing, rightSideBearing, characterWidth, rawCharacterWidth,
ascent, descent;
! int i = 0;
face = instance-face;
smetrics = instance-size-metrics;
--- 567,577
char *raster = NULL;
FT_Size_Metrics smetrics;
FT_Glyph_Metrics *metrics;
! int wd, ht, bpr;/* width, height, bytes per row */
! int dx, dy;
int leftSideBearing, rightSideBearing, characterWidth, rawCharacterWidth,
ascent, descent;
! int i = 0, j;
face = instance-face;
smetrics = instance-size-metrics;
***
*** 579,590
bitmap = face-face-glyph-bitmap;
if(hasMetrics) {
! wd = tgp-metrics.rightSideBearing;
! ht = tgp-metrics.ascent;
} else {
wd = bitmap-width;
ht = bitmap-rows;
!
/* The X convention is to consider a character with an empty
* bounding box as undefined. This convention is broken. */
if(wd = 0) wd = 1;
--- 582,597
bitmap = face-face-glyph-bitmap;
if(hasMetrics) {
! wd = tgp-metrics.rightSideBearing - tgp-metrics.leftSideBearing;
! ht = tgp-metrics.ascent + tgp-metrics.descent;
! dx = -tgp-metrics.leftSideBearing +
! TRANSFORM_X(metrics-horiBearingX);
! dy = tgp-metrics.ascent - TRANSFORM_Y(metrics-horiBearingY);
} else {
wd = bitmap-width;
ht = bitmap-rows;
! dx = 0;
! dy = 0;
/* The X convention is to consider a character with an empty
* bounding box as undefined. This convention is broken. */
if(wd = 0) wd = 1;
***
*** 601,613
memset(raster, 0, ht * bpr);
}
! if(bpr == bitmap-pitch) {
memcpy(raster, bitmap-buffer, bitmap-rows * bitmap-pitch);
! } else {
! for(i = 0; i bitmap-rows; i++)
! memcpy(raster + i * bpr,
bitmap-buffer + i * bitmap-pitch,
bitmap-pitch);
}
tgp-bits = raster;
--- 608,635
memset(raster, 0, ht * bpr);
}
! if(dx == 0 dy == 0 bpr == bitmap-pitch) {
memcpy(raster, bitmap-buffer, bitmap-rows * bitmap-pitch);
! } else if(dx == 0) {
! for(i = MAX(0, -dy); i bitmap-rows i + dy ht; i++)
! memcpy(raster + (i + dy) * bpr,
bitmap-buffer + i * bitmap-pitch,
bitmap-pitch);
+ } else {
+ int dx8;
+ if(dx % 8 == 0)
+ dx8 = 0;
+ else if(dx = 0)
+ dx8 = dx % 8;
+ else
+ dx8 = dx % 8 + 8;
+ for(i = MAX(0, -dy); i bitmap-rows i + dy ht; i++)
+ for(j = MAX(0, -dx); j bitmap-width j + dx wd; j++) {
+ raster[(i + dy) * bpr + (j + dx) / 8] |=
+ ((bitmap-buffer[i * bitmap-pitch + j / 8]
+ (0x80 (j % 8
+ ((j % 8 + dx8 8)?dx8:(8 - dx8));
+ }
}
tgp-bits = raster;
[Fonts]FreeType 2 backend for the masses
The FreeType 2 backend and the latest version of mkfontscale are available from http://www.pps.jussieu.fr/~jch/software/files/ Everybody can change his mind. The files are: xfree86-freetype-2.1.1.patch : imports FreeType 2.1.1 into XFree86; xfree86-freetype2-20020620.tar.gz : latest FreeType 2 backend; mkfontscale-20020618.tar.gz : latest version of mkfontscale. Instructions: $ rm -rf xc/extras/freetype2 xc/lib/font/FreeType xc/programs/mkfontscale untar freetype-2.1.1.tar.gz under /tmp $ mv /tmp/freetype-2.1.1 xc/extras/freetype2 apply xfree86-freetype-2.1.1.patch untar xfree86-freetype2-20020620.tar.gz untar mkfontscale-20020618.tar.gz $ make World Version 20020620 includes the patch I've just sent to the list. Neither the backend nor mkfontscale will build with versions of FreeType older than 2.1.1. For people using older versions of mkfontscale, please upgrade. Previous versions had a minor bug that interacts badly with a bug in FreeType 2.1.1; this version of mkfontscale should be immune. (For anyone interested: previous versions of mkfontscale failed to activate the right cmap. This was okay in 2.0.9, which would provide a default cmap which turned out to be the right one in most cases, but breaks in 2.1.1, which fails to do so.) Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]FreeType 2 backend for the masses
JP [...] either the instructions or the sources should be adapted. I was only checking if anyone's paying attention ;-) Nice to see you back, Joerg. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Fcpackage release candidate 1
KP eliminate per-file syscalls when the cache file is up-to-date. Could you explain what exactly you're trying to avoid and how you achieve that? 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
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]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]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 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
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
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]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
[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 stdlib.h
#include stdio.h
#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]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]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
[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
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
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
[Fonts]Fonttootf: first cut of a BDF-TTF converter available
Hello, The first cut of fonttootf, a BDF to snft (TTF or OTF) converter for bitmap fonts is available from http://www.pps.jussieu.fr/~jch/software/files/fonttootf-20020821.tar.gz This is an early beta, please do not redistribute this version. A few caveats. First, you need a version of FreeType that contains the bug fix of August 19; this means current CVS. Second, due to another bug, you will not be able to use this code on BDF fonts (you'll need to convert to PCF first). Second, the Microsoft TrueType, Apple TrueType and OpenType specs differ on what tables are compulsory. Microsoft TrueType makes all tables compulsory. OpenType makes loca and glyf optional (but hmtx compulsory), while Apple TrueType makes all tables optional. Thus, fonttootf can generate different variants of fonts with the -m and -g flags. Please see the man page for details. In short, though, FreeType works with -g at least 2 and -m at least 1. Pfaedit requires -g 3. The cases -g 2 and -m 0 violate the OpenType spec; all other cases are legal. Here's a summary of font sizes: (1) (2) (3) .pcf.pcf.gz pfaedit fonttootf fonttotf -c 8x13-L1.pcf 19572 4579 6908 40124032 8x13.pcf41066057158 54044 52244 helvR14.pcf 7180413901 15780 15796 9x18.pcf + 18x18ja.pcf77976 + 580901 796464 917620 All sizes are in bytes. Column (1) is the size of the TTF generated by pfaedit; I didn't try to tune pfaedit's options -- this is not meant as a fair comparison, but rather as a baseline. Colum (2) is the size of the TTF generated by fonttootf by default; column (3) is the size of the TTF generated by fonttootf with glyph cropping disabled. The first font is a small (196 glyphs) small (8x13) charcell font. The second is a large (almost 4000 glyphs) small (8x13) charcell font. The third is a small (196 glyphs) small (14 ppem) variable width font. The fourth is a large large bi-width font generated from two charcell fonts (yep, fonttootf can do that). As you'll notice, cropping doesn't buy you much. In the case of the variable font, this is expected, as the font is already cropped (except that spaces are represented as 1x1 bitmaps, cropping eliminates the bitmaps altogether). In the case of the charcell and bi-width fonts, cropping does reduce the bitmap data quite a bit; however, the glyphs then have variable metrics, which prevents fonttootf from optimising the metrics table by encoding metrics only once. Thus, the gain in bitmap data is mostly offset by the larger metadata. Only in the case of the 18-pixel font, where the bitmap data dominates the font size, is cropping worthwile. Here's a selection of table sizes for the three TTFs generated from 8x13-L1.pcf. EBDT (bitmap data): (1) 2468, (2) 2272, (3) 2903. In case (2), we gain some w.r.t. pfaedit by writing metric-less bitmaps whenever possible. In case (3), the bitmap data is much larger, but all bitmaps are metric-less (as they are all equal) which makes the EBDT only slightly larger. EBLC (bitmap index): (1) 968 , (2) 698, (3) 84. As above. In case (2), some EBDT subtables have been replaced by metric-less tables. In case (3), there is a single metric-less table, and the EBLC is tiny. cmap (character to index mapping): (1) 698, (2) 52, (3) 52. Here we simply order all glyphs so that the cmap table is trivial. Pfaedit orders the glyph in what appears to be a random order, and therefore has to output a complex cmap. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] 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
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]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]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
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]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
[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
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
[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
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]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
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
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]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]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]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
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]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). JSDoes 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]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]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
[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
[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
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] 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] 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] 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] 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] 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.glyph3) - 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.glyph3) - 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] 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] 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 [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] [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] 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
[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
[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] 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
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
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.
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.
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.
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.
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] 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] Font alias
locate README.fonts 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] 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 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
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
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
