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.O
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://XFree
MK> These bracket components will hopefully *NOT* be missunderstood by
MK> the maths layout community as the proper way to typeset
MK> mathematical formulas. (*a feeling of horror crawls down my spine
MK> just from the thought*)
While I agree with you that such components have nothing to do in a
AB> Thinking about it, if X allows you to set an arbitrary
AB> resolution (whether by choice or because your monitor tells
AB> X that it can do 101 DPI), is it safe to assume that X will
AB> correctly scale vector fonts accordingly?
It's done at the toolkit level. The X server merely passes back
YS> The new patch fixed all the problems I mentioned, Thanks!
Great, thanks for the report.
Juliusz
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
YS>
http://mirror.aarnet.edu.au/pub/redhat/redhat-7.3-en/os/i386/RedHat/RPMS/ttfonts-zh_CN-2.11-21.noarch.rpm
I'm getting connection timeouts. Any other site?
I've tested with the Arphic fonts, and cannot see any problem. If you
still see issues with the latest version (with the -c- patch), p
>> P.S. Anybody got clean code to do a 1bpp unaligned blit?
KP> There are plenty of examples in the fb code; do you need something more
KP> targeted?
Yep. If you look at my previous patch, you'll find the code that I've
appended to this message. It has two bitmaps, both of which are 1bpp
MSBF
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 Fre
KP> fontenc uses the old static configuration model from the core system,
KP> fixing fontenc would be a bunch of work.
Er... That's libfont, not fontenc. The only configuration that
fontenc requires is the presence of the global font encodings
directory (lib/X11/fonts/encodings/encodings.dir).
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
-
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 te
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
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
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
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)
>> 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
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.
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
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
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
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
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,
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
>> 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
[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
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
> 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
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
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
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
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
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
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
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
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. D
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
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
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
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
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> 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
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
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
___
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
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
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
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
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
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
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
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
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
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
___
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
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
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
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
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
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
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
>> 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.
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
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
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
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
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
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
>> 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
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
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
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
>> 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
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
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
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
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
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
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
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
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.
[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
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
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
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
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
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
>> 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).
>> 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
>> (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,
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
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
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
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
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
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
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
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
> 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
101 - 200 of 211 matches
Mail list logo
