Dear all,
While I haven't finished reading the code to Xft yet, I've got a
couple of comments that may be useful to some.
1. The config file
1.1 People have been making comments to the effect that the config
file language is too expressive[1], and therefore difficult or
impossible to process au
>> 1.1 People have been making comments to the effect that the config
>> file language is too expressive[1], and therefore difficult or
>> impossible to process automatically.
KP> I don't think anyone has complained about it's expressive power,
KP> only about the complexity of specifying simple t
KP> Have you missed my user and domain name for all these years?
I took it for a private interface.
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Thanks, Dimitry. I'll never understand how shell quoting works.
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Technically, there is no such thing as a PostScript font; you probably
mean Type 1 fonts, although you may also want to check for CIDFonts.
After opening a font (or after doing a QueryFont request), you can
check the values of the following properties:
FONT_TYPE (should be ``Type 1'');
RASTE
Hello,
I am soon going to include a new set of Bigelow and Holmes Luxi
(formerly Lucidux) fonts in the tree.
The new fonts have a larger character repertoire than the version
currently in the tree. Unlike the old fonts, which were in Type 1
format, the new fonts are TrueType.
For various reaso
Yibo,
YW> I am building Xfbdev for iPAQ H3630, and I need to support
YW> Chinese GB2312 truetype font. So I want to build X-TrueType, but
YW> failed. Who can tell me whether Xfbdev support X-TrueType now? If
YW> it can, how to realize this? Thank you!
I've never tried to build KDrive with X-T
Hello to all,
I have just submitted the new Bigelow & Holmes Luxi (formerly Lucidux)
fonts for inclusion in XFree86; they are available to XFree86 members
as patch number 5010.
Main news:
- bold versions are available, leading to a complete family (r, i, b
and b-i);
- both Type 1 and TrueT
> A question from non-XFree86 member: do these new
> versions include cyrillic (and, maybe, greek) glyphs, or is
> the repertoire still limited to latin?
Their repertoire is limited to the Latin script.
Charles Bigelow, who has kindly donated these fonts, is a typographer
who specialis
JC> Their repertoire is limited to the Latin script.
NB> What Latin? Only ISO-8859-1 or something else also?
ISO 8859-1, -2, -3, -4, -9, -10, -15, Adobe Standard and the
Windows 3.1 character set.
So Lithuanian is fine.
Juliusz
S> I have almost completed the Bengali code-point glyphs I mentioned
S> as while ago.
Cool. I suggest we have a look after 4.2.0 is out (it's frozen right
now).
S> 1. What license do you prefer? GPL? X?
We will not accept anything under the GPL. (Not my choice, that's
what the Core Team has
S> pfaedit has an auto-hinting capability supporting horizontal, vertical and
S> diagonal hints - if that is enough, we are there already.
I'm not sure how good their autohinting is. I think that the best
solution would be to start with the generated hints, and then retouch
them by hand where n
JT> I have a large number of TrueType fonts installed on my system (just over
JT> 1000).
JT> Under KWord the font selection drop down box gives a preview of every font.
JT> Whenver I scroll quickly up and down the list, xfs crashes!
Most likely, it's neither an xfs problem nor a problem with t
Mike,
MH> Start up xfs, and it should be fine.
Yours is a RedHat-specific reply. Debian do things more reasonably,
and don't require a font server by default.
MH> I see people with this common problem a lot. In Red Hat Linux,
Your predecessors at RedHat have chosen to unconditionally rely on
DV> I am installing xfstt (TrueType Fonts Server for X)
Dear Daniel,
Xfstt (no relation to xfsft) is completely independent of XFree86. We
are unable to help you with it; a posting to a relevant Usenet
newsgroup may be more useful.
Please note that XFree86 4.0 and later have native support for
Patch 5064 (Luxi Fonts, Jogailla release) is in the archive for your
testing pleasure.
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Sorry if my formulation was overly provocative. I've seen you take a
more relaxed attitude in the past, and I was hoping it would be okay
with you. But it's November, and we're all losing our sense of humour
somewhat.
I'll stick to the dry facts, then.
MH> There are both circumstances where us
xlsfonts -u -fn "blah"
^^
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
AS> I need some docs about the meaning of the numbers after
AS> X Error of failed request:
AS> Major opcode of failed request:
AS> Serial number of failed request:
AS> Current serial number in output stream:
They won't give you any information. Error reporting of core font
problems is sadl
>> (iii) workaround for the server hang during rasterisation of large fonts.
PS> (v) (maybe obsolete now) if the server is not multithreaded, it was better
PS> to use a font server, as rasterization of a large font didn't freeze
PS> the whole X, but only the program requesting that font,
>> That's interesting. Why is it different from doing xset fp ... from
>> your Xsession file?
KP> Because 'xset fp default' would not have the same behaviour?
I see.
How does Pablo's suggestion sound to you? Would it be useful?
Off the top of my head, unless there are problems with fontlib's
>> 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).
PS> Yes, everything can be done from $HOME/.Xsession or $HOME/.profile
PS> however that is complex and fragile.
PS> But if I think that XF86Config file is complex, then $HOME/.Xsession or
PS> $HOME/.profile are much worst! (well, usually they are quite small,
PS> but there is virtually no limit to
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
Dr Andrew C Aitchison writes:
AA> I thought (hoped?) that the scalable font renderers could cope with
AA> unusual dot pitches.
The scalable renderers will indeed handle reasonable font pitches fine.
The only issue I can see is the one of delta hints in TrueType
fonts. Delta hints apply to one
SRH> Since I am interested in outline Bengali fonts, I take it that I
SRH> should go with TT for now, moving to OT as support improves.
Shaheed,
There are two questions to consider:
(i) is your encoding no larger than 256 glyphs?
(ii) are all the glyphs you wish to include in Unicode?
If
OT> For Type1 outlines, I'd say that OpenType is the best format long
OT> term. I don't think we handle it all that well yet, but for
OT> "interesting" scripts PFA/AFM really isn't an option.
I don't quite agree. Plain Type 1 fonts (PFAs) can obey any *glyph*
encoding, and are not restricted to
OT> having a commonly agreed upon glyph set is [a pain]
[problem description]
OT> a way of representing the character to glyph mapping in a flexible
OT> way starts seeming pretty attractive.
Owen, we fully agree. I just thought your formulation was overly
categorical -- there are many situatio
[CC'd to the fonts list, in case somebody wants to comment.]
Hi David,
DD> I just noticed that mkfontdir will remove an existing encodings.dir file
DD> even when it's not going to write out a new one.
I'm sorry, my development machine (the one that doesn't belong to my
employer) is currently de
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.
Dear Eli,
I am sorry I have missed the beginning of this discussion; I hope I'm
not repeating things that have already been said.
I am the person who implemented on-the-fly font recoding in XFree86
4.0, which is what you are complaining about. Please read the
``README.fonts'' document for a rat
PS> However, it seems that for Type1 fonts the encoding is handled
PS> internally; no matter what I put in the enc file the result is
PS> this the same [...] or I need to restart X or something?)
Remember that font encodings are indexed by name and cached in the
server. You do need to restart th
PS> When a TTF font is requested trough an unknown encoding (eg:
PS> *-iso8859-0 ) the default seems to be the same as
PS> microsoft-win3.1,
No, the default is ``iso8859-1''.
PS> Now, for postscript fonts, wouldn't it be better to have the default
PS> as being the same as -adobe-fontspecific ins
KP> Are there compelling reasons *not* to use the CSS2 matching algorithm?
Raph Levien once spoke some strong words about CSS 2. Raph, any
chance you could enlighten us?
[Background: this is the XFree86 font list, and Keith Packard is
sort-of-seriously thinking about unifying the font configura
I'm not quite clear about the client/server split. Am I correct in my
understanding that when using Xst, the STSF library is on the server
side? And that only the X server ever speaks to the ST server?
Thanks,
Juliusz Chrob
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
JC> It's not that I have a problem understanding the instructions,
JC> since they're pretty easy to follow.
That's good to hear -- I haven't received feedback about this section yet.
JC> The problem I have is whether I really have to create entries for all
JC> 50 Adobe-Japan1 CMaps for all four
>> 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.
PS> Why?
Roughly two years ago, Markus, I, Peter Deutsch, some people from
URW++ (sorr
James, Eric,
As you will have noticed, the CIDFonts stuff is badly in need of more
detailed documentation. When you puzzle out how to make XFree86
usable with CIDFonts, I'll be very grateful if you can produce a
summary suitable for inclusion in the fonts docs.
I may be wrong, but I believe tha
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
JC> The result is that PK's compression is subliniear on this face at mag
JC> factors less than 14 and superlinear above mag factor 14.
PK does run-length encoding, right? Then it should be linear as the
point-size goes towards infinity (i.e. after the effects of MF's
optical scaling are no long
>> The glyph names used by the Type 1 backend are defined by an Adobe
>> standard, with a few changes for compatibility with X11R5 (e.g. U+0027
>> maps to a closing quotation mark rather than a vertical apostrophe,
MK> Unfortunately ... :-(
Do we want to change this? This change would make XFre
MK> I am being told that the next SI will be fully XFree86 compatible in
MK> that respect.
By whom?
MK> Please follow Adobe's character name <-> Unicode mapping strictly.
MK> Please do not add any backwards compatibility hacks for curly 0x27 that
MK> will cause incompatibility with the corrected
JC> Has anyone done any work towards porting the freetype (server-side)
JC> font module from ft1 to ft2?
I've played with it, and then Real Work caught up with me.
JC> I was thinking about taking a crack at it if no one else is.
Go for it. Feel free to get in touch with me if you need any help
JAC> The first problem I encounter is that mkcfm doesn't seem to recognize
JAC> the Hiragino fonts. None of them. It creates CFMs for the Wadalab
JAC> fonts, but none for the Hiragino fonts. I have no idea why. I
JAC> haven't tried stepping it through GDB but I could.
It may very well be a re
Mike, Pablo,
My apologies for not replying earlier -- I'm catching up on my mail.
Mike's assumption is correct -- it should now be possible to remove
all encodings files except for the one in fonts/encodings. The new
mechanism is as follows: first, the font's directory is searched for
encodings
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 fo
JAC> I didn't have sufficient context to understand, but that's what I
JAC> meant to mean. I haven't studied XFree86's font guts closely... I'm
JAC> more on the user end of things.
JAC> Can the FreeType T1 backend handle more than 256 codepoints in a Type
JAC> 1 font?
We do not currently have
>> It may very well be a resource exhaustion. The Type 1/CIDFont
>> renderer uses a fair number of fixed size tables. You could try
>> tweaking the defines for the VM sizes.
JAC> Great! Where do I look?
lib/font/Type1/util.h. VM_SIZE would be my first guess.
YS> Does any XFree's rasterizer, either freetype or xtt support TrueType
YS> Embedded Bitmap?
freetype -- no.
xtt -- yes.
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/font
H> Can anyone explain why some fonts are available in both AA and
H> non-AA, some are only available in AA, and some only in non-AA.
Discrepancies between fonts.scale and the set of fonts.
Juliusz
___
Fonts mail
Dear all,
An early BETA of a TrueType and Type 1 backend for XFree86 4.2.0 and
later is available from
http://www.pps.jussieu.fr/~jch/software/files/
in the files
xfree86-freetype2-03042002.tar.gz
xfree86-freetype2.patch
(Yes, you need both.)
This is a beta version, and is not ready fo
Dear David, dear all,
I'm currently working on a FreeType 2 backend for XFree86. My goal
was to use pristine FreeType sources and only have a private set of
config files; unfortunately, that has proven impossible for two
reasons. I would like to suggest that a number of minor changes to
FreeTyp
Hello,
Continuing the effort to get rid of obsolete font rendering libraries,
I've written a font configuration utility for XFree86 based on
FreeType 2. It is similar to Joerg Pommnitz's ``ttmkfdir'', but uses
fontenc for encodings (thus guaranteeing consistency with the
encodings known to the X
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
___
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 wrapp
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 s
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
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
TW> Say I wish to use a CIDfont, Ryumin-Light, with UniJIS-UTF8-H
TW> CMap, what should I do?
Read the docs? For example, chapter 7 of the PLRM and Adobe technote
5014. You will find both somewhere under
http://partners.adobe.com/asn/developer/technotes/main.html
JC> Of the fonts I have licensed, Lucida Bright Oblique is the only one I
JC> can think of with a non [0.001 0 0 0.001 0 0] matrix, which obliques
JC> by just changing the matrix.
A large number of oblique (as opposed to italic) fonts use this trick;
for example, the Type 1 versions of the Lucidu
Dear all,
Unlike the Type 1 backend, the FreeType backend doesn't provide
clients with an accurate average width. What it does is to provide
accurate average width for monospaced fonts (obviously), and just give
half the maximum advance width for proportional fonts.
While this heuristic works r
New versions of both mkfontscale and the FreeType 2 backend are
available from
http://www.pps.jussieu.fr/~jch/software/files/
Note that you will need to apply the ``xfree86-freetype2.patch'' even
if you've done before, as this version contains a little more stuff.
I gratefully acknowledge the
DT> I think it was a bug in the Type 1 driver that was fixed in 2.1.0
DT> Could you tell me if it still persists ??
It's more reasonable, but still not quite consistent between Type 1
and TrueType. This may very well be the correct behaviour, though, as
the TrueType versions have much larger gly
YS> Red Hat will use a updated ttmkfdir in the next release, we
YS> updated the ttmkfdir to FreeType2 and also added some other CJK
YS> releated features(like TTCap), and it uses system encodings.dir as
YS> default to recognize font encodings.
Mkfontscale does all of that except for TTCap (which
IM> I saw the ``xfree86-freetype2.patch'', and I found it does not
IM> contain ftstdlib.h related chank. It is still needed.
Thanks for the report. I forgot ``-N''.
I'll generate a new patch ASAP.
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 als
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
Corrected `xfree86-freetype2.patch'' following Ishikawa-san's report.
Mkfontscale: corrected typo and added support for discriminating
between italic and oblique fonts.
As usual,
http://www.pps.jussieu.fr/~jch/software/files/
Juliusz
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
Keith Packard <[EMAIL PROTECTED]>:
KP> Are you now using the regular .so for your server-side module?
That's the plan ultimately (I wouldn't dare disobey Keith), but it's
still premature for two reasons.
I'm currently using two internal interfaces, which I don't wish to
export to server modules
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 an
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 PROTECTE
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. D
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?
Dear all,
As I'm getting ready to include the new FreeType backend in XFree86, I
have a configuration problem.
The old FreeType backend (currently in CVS) only registers for TTF
fonts. The new FreeType backend registers for TTF, OTF and PFA/PFB
fonts. This makes it incompatible with the Type 1
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 curren
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 font
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
Dear David, dear Werner, dear all,
In the FreeType 2 module for XFree86 and in the mkfontscale utility, I
am using a number of internal interfaces. I am attaching a proposed
interface for these, as well as the rather hackish implementation I'm
using right now.
Of course, I have no objection to
Dear all,
As some of you may know, the new FreeType backend registers itself for
Type 1 fonts. This means that it cannot be loaded together with the
current Type 1 backend.
Unfortunately, the FreeType backend does not yet support CIDFonts.
This means that with the new FreeType backend, you will
> 1. I have to set -f 3 to get KAIU.TTF and MINGLIU.TTC with big5-0
[...]
> 2. The default ``fuzz'' value can find the encodings correctly for all
> four arphic ttf.
[...]
> 3. For baekmuk ttf, it missed this font for 'ksc5601.1987-0' encoding with
> default ``fuzz'' value.
> hline.ttf -ibm-Ba
RG> Well, all the ttf I tested are Unicode fonts but we still need specific
RG> encodings to use them with most applications.
The point I was making is that in practice the fuzz value will only be
used for East-Asian encodings, and I'm therefore glad to set it to
whatever value users of such enco
[CC-ing the list propter majorem sapientiae condivisionem]
> In SuSE Linux 7.3 I had lots of handedited fonts.scale.
> files, which I merged into a fonts.scale file with
> /sbin/conf.d/SuSEconfig.fonts. I absolutely needed these handedited
> files because the output of ttmkfdir was too bad to gen
>> I have seem many times in this mailing list, on the term 'language tag'.
KP> This comes from the OS/2 tables [in TrueType and OpenType fonts].
KP> There are 64 bits in this table which were originally designed to
KP> indicate which "CodePages" the font supported,
The term ``language tag'' is
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
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,
Hello,
The attached patch is supposed to remove the bitmap scaler from
XFree86. It has only been tested with KDrive, not with the XFree86
server. I'm fairly confident it doesn't break XFree86, but I
wouldn't be surprised if it broke Xprt. (Not that anybody cares.)
I'll be glad to receive feed
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
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 page
TK> How about making a single, multiplatform and program independant
TK> library, that can deliver those functionnailities to our programs?
It exists and is standardised. See iconv(3).
Unfortunately, iconv is not equally supported on all platforms; which
is why a multi-platform project such as
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.
>> Unfortunately, iconv is not equally supported on all platforms; which
>> is why a multi-platform project such as XFree86 needs to roll its own.
BH> Juliusz, you know that GNU libiconv is portable to any system that
BH> runs X applications.
Sorry, you're right.
BH> The real reason why iconv i
Patch 5289 is broken for two distinct reasons. Please don't apply it.
First, it breaks all scalable fonts. The fix is to make the
``:unscaled'' hack only apply to non-scalable entries (attached purely
for your information -- I don't suggest committing anything in the
current state of the beast)
KP> I was unaware that any foundrys were spending the time and money to build
KP> fonts in this fashion any more. It would be nice...
I think you can still get digital fonts rasterised from different
masters. Adobe, for example, sell Times in both the 12 pt (that's the
one in your printer) 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> -b&h-Luxi Mono-medium-r-normal--[9.75 0 0 13]-0-75-75-m-0-iso8859-1
JC> while intended to match those
Dear all,
A new version of the FreeType 2 backend is available on
http://www.pps.jussieu.fr/~jch/software/files/xfree86-freetype-20020612.tar.gz
This version will build against an unpatched tree of FreeType 2, but
it absolutely requires FreeType 2.1.1. Note that you do not need to
have it in
1 - 100 of 211 matches
Mail list logo