Being lazy, I'm asking here before actually looking around. Can anyone
recommend programs that create [OT]TF fonts from BDF fonts?
[I] seem to recall that someone on one of the Freetype lists might
have also written one;
You may be thinking of my fonttosfnt. It does something completely
I tried fonttosfnt some weeeks ago and found that it uses
FT_Bitmap_Size-{height,width} for ppemY and ppemX. Shouldn't it be
ppemX = ppemY = FT_Bitmap_Size-y_ppem?
The reason that ppemX should be equal to ppemY is that an em-sqaure with
unequal ppems means x and y axes are scaled
It's not terribly useful for fontconfig or libXft, where it is useful is
in converting sfnt back into BDF files in case you want to take a font
and use it with old non-TTF supporting X servers.
Well, that you already can do, using fstobdf (it's still in the tree,
right?). Now, if there are
BTW, have we finally decided that such fonts have the extension .otb?
This was discussed on the xfree86-fonts and -devel lists a long time
ago (before the events), and this was definitely the best suggestion.
In particular, it was only used by one obscure piece of MS-DOS software,
and works on
The bytecode interpreter is disabled.
http://bugs.xfree86.org/show_bug.cgi?id=666
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
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
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
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
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
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
locate README.fonts
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/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?
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
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
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
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
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
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
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
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.
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.
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
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.
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
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
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?
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
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
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
***
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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.
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.
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
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.
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
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
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
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
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]
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.
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.pcf
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
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
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
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
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]
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.
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,
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
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
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
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
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
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
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]
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
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
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
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]
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
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
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
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
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.
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?
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
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
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,
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
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
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
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
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?
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.
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.)
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
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
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
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
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
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
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
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)
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
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
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
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
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
1 - 100 of 105 matches
Mail list logo
