Re: [Fonts]Help with fixed fonts
Around 12 o'clock on Dec 6, Francesco Zappa Nardelli wrote: > if (!strcmp(FT_MODULE_CLASS(face->driver->root)->module_name, "pcf")) > pcfface = (PCF_Public_Face)face; Thanks muchly; I'll go and figure out how to make the encodings work. Do you have this patch: Index: src/pcf/pcfdriver.c === RCS file: /home/x-cvs/xc/extras/freetype2/src/pcf/pcfdriver.c,v retrieving revision 1.1.1.2 diff -r1.1.1.2 pcfdriver.c 122a123,124 > size->metrics.max_advance = face->accel.maxbounds.characterWidth << 6; > in your current PCF driver? It sets the max_advance for monospaced fonts and is kinda necessary for Xft to use PCF fonts. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
KP> My question should have been: KP> FT_New_Face( library,..., &face ); KP> KP> pcfface = (PCF_Public_Face)face; KP> How to I know this cast is correct? Where is the check that ensures the KP> call to FT_New_Face has found a PCF font rather than a TrueType font? Something like FT_New_Face( library,..., &face ); if (!strcmp(FT_MODULE_CLASS(face->driver->root)->module_name, "pcf")) pcfface = (PCF_Public_Face)face; should do the trick. Regards, -francesco ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
FZ> FT_New_Face( library,..., &face ); FZ> FZ> pcfface = (PCF_Public_Face)face; KP> How to I know this cast is correct? Where is the check that ensures the KP> call to FT_New_Face has found a PCF font rather than a TrueType font? There is an handler to the driver in the FT_Face object. But I prefer to check this with FreeType's gurus... -francesco ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Around 18 o'clock on Dec 5, Francesco Zappa Nardelli wrote: > As far as I know, all drivers are tested in the order specified in > ftmodule.h. The first one that returns a FT_Face (instead of an > error) is chosen. My question should have been: > FT_New_Face( library,..., &face ); > > pcfface = (PCF_Public_Face)face; How to I know this cast is correct? Where is the check that ensures the call to FT_New_Face has found a PCF font rather than a TrueType font? Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
KP> Around 17 o'clock on Dec 5, Francesco Zappa Nardelli wrote: >> On the other hand, each pcf font defines >> two properties that specify encoding and registry. >> I decided to make these two properties directly accessible, leaving to the >> client application the work of interpreting them. For instance: KP> That seems like a reasonable mechanism; I've got encoding files that I can KP> identify from the PCF file properties. KP> What is the official mechanism for determining which driver is responsible KP> for a particular FT_Face? As far as I know, all drivers are tested in the order specified in ftmodule.h. The first one that returns a FT_Face (instead of an error) is chosen. -francesco ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Around 17 o'clock on Dec 5, Francesco Zappa Nardelli wrote: > On the other hand, each pcf font defines > two properties that specify encoding and registry. > I decided to make these two properties directly accessible, leaving to the > client application the work of interpreting them. For instance: That seems like a reasonable mechanism; I've got encoding files that I can identify from the PCF file properties. What is the official mechanism for determining which driver is responsible for a particular FT_Face? Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
KP> XFree86 ships with a large number of mappings, and it would be KP> useful to either have the encoding name exposed so we can go get KP> the mapping. The pcf driver will expose all the properties of a pcf font as soon as possible. About the encoding name... [From the pcf driver readme] Encodings * The variety of encodings that accompanies pcf fonts appears to encompass the small set defined in freetype.h. On the other hand, each pcf font defines two properties that specify encoding and registry. I decided to make these two properties directly accessible, leaving to the client application the work of interpreting them. For instance: #include "pcftypes.h" /* include/freetype/internal/pcftypes.h */ FT_Face face; PCF_Public_Face pcfface; FT_New_Face( library,..., &face ); pcfface = (PCF_Public_Face)face; if ((pcfface->charset_registry == "ISO10646") && (pcfface->charset_encoding) == "1")) [..] Thus the driver always export ``ft_encoding_none'' as face->charmap.encoding. FT_Get_Char_Index() behavior is unmodified, that is, it converts the ULong value given as argument into the corresponding glyph number. Regards, -francesco ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Around 11 o'clock on Dec 5, Francesco Zappa Nardelli wrote: > Properties are parsed by the pcf driver. I don't remember if they are > exposed to the client. This should be simple to add (next weekend). Thanks; I'd like to throw all of the other X font mechanisms away and use only FreeType in the future. > Please, let me know if you need any improvement to the pcf driver. Yes, we'll need the ability to reencode fonts from non Latin-1/Unicode encodings. XFree86 ships with a large number of mappings, and it would be useful to either have the encoding name exposed so we can go get the mapping. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
KP> I'll check to see whether this information is exposed through KP> FreeType for .pcf files. Properties are parsed by the pcf driver. I don't remember if they are exposed to the client. This should be simple to add (next weekend). Please, let me know if you need any improvement to the pcf driver. Regards, -francesco ___ 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]Help with fixed fonts
Around 12 o'clock on Dec 1, Juliusz Chroboczek wrote: > Can you provide me with some code to produce a list of pairs of > (XLFD, filename) out of an Xft config file? Hmm. I can give you everything except average width; for that field, I'd have to rasterize the appropriate subset of the font and compute it. Certainly for the scalable names, it's easy enough. You can play with the existing XftListFonts interface if you want to see how it might work. The essential operation is to list the fonts with an empty pattern and a selection of all of the fields you're interested in, for XLFD, that will be XFT_FOUNDRY, XFT_FAMILY, XFT_WEIGHT, XFT_SLANT, XFT_STYLE, XFT_PIXEL_SIZE, XFT_SIZE and XFT_SPACING; the file name is available as well if you want (XFT_FILE), but it's not relevant for listing fonts. Not all fonts will include all values, so you'll have to do a bit of defaulting; fonts without XFT_SIZE or XFT_PIXEL_SIZE are scalable. Figuring out the list of supported encodings will require a small amount of additional work; you'll want to use the new font configuration library for that as it includes unicode coverage in the font name itself, then select encodings which are reasonably well covered by the font. Keith PackardXFree86 Core TeamSuSE, Inc. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
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 what you can put on them) I was actually thinking of a machine-maintained .private-fonts that is sourced by the system-wide session file. Assuming that you document the fact that the user is not allowed to munge this file, it would be almost equivalent to having the configuration mechanism you're proposing. In other words: the main problem you're describing is the lack of a well-defined boundary between user- and machine-maintained configuration files, a problem that is rampant throughout Unix-like systems. Keith is right, though, that it would confuse the hell out of xset fp default. 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
Kaixo! On Fri, Nov 30, 2001 at 05:08:27PM +, Juliusz Chroboczek wrote: > PS> In other words, if there were a possibility to use an external > PS> config file for font handling done by the X server (maybe a > PS> special fontpath like "config:/etc/X11/somefile" ), then I would > PS> be happy to drop default use of xfs and use that feature instead. > > That's interesting. Why is it different from doing xset fp ... from > your Xsession file? Yes, everything can be done from $HOME/.Xsession or $HOME/.profile however that is complex and fragile. But if I think that XF86Config file is complex, then $HOME/.Xsession or $HOME/.profile are much worst! (well, usually they are quite small, but there is virtually no limit to what you can put on them) It will also be still less standard, I think. -- Ki ça vos våye bén, Pablo Saratxaga http://www.srtxg.easynet.be/PGP Key available, key ID: 0x8F0E4975 ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Around 18 o'clock on Nov 30, Juliusz Chroboczek wrote: > 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? In principle, it sounds fine. Instead of creating a new configuration mechanism, we should simply use the one underlying Xft. That would have the benefit of also supporting the new font name syntax (as well as XLFD). Keith PackardXFree86 Core TeamSuSE, Inc. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
>> 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 reentrancy, it doesn't sound impossible to implement in finite time. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Around 17 o'clock on Nov 30, Juliusz Chroboczek wrote: > That's interesting. Why is it different from doing xset fp ... from > your Xsession file? Because 'xset fp default' would not have the same behaviour? Keith PackardXFree86 Core TeamSuSE, Inc. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
>> (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, until the PS> rasterization ends. That's my point (iii). It's still the case, except for a special hack for charcell TrueType fonts. PS> In other words, if there were a possibility to use an external PS> config file for font handling done by the X server (maybe a PS> special fontpath like "config:/etc/X11/somefile" ), then I would PS> be happy to drop default use of xfs and use that feature instead. That's interesting. Why is it different from doing xset fp ... from your Xsession file? Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Keith Packard wrote: > ... [text about the benefits of client side font handling] We singing in the same choir. > To some extent; this just means that clients are in control > of their fate. Place fonts in the X server and you can add > features to *all* applications in one place. Yes, but two years later after people have upgraded their X server (when they upgraded their OS). There is no mechanism to automatically upgrade the X server and I think it silly and presumptive to ask users to disturb their environment to add a feature to an app (that is assuming they even know that this is a possibility). I certainly would balk if mozilla told me I had to upgrade my X server to get a feature and I'm a mozilla developer. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Around 9 o'clock on Nov 29, Brian Stell wrote: > The choice to put X font handling on the server as opposed > to the client has some advantages (feel free to add more): > > sharing a common resource => memory savings > > the pixels are at the X server => minimal network bandwidth Of course, the most obvious reason is that when X was developed, it was commonly expected that the graphics API would provide a list of fonts -- printers inclued embedded fonts, text-mode terminals had embedded fonts. All major window systems from that era placed font handling below the API. > The choice to put X font handling on the server as opposed > to the client has some disadvantages (feel free to add more): One of the most severe problems we have today is that modern fonts have hundreds or thousands of glyphs. The core X font mechanism requires that all of them be rasterized before the first one can be used; this takes a long time. Replace that with some incremental mechanism and the client will execute dozens of round trips as new glyphs are needed -- the metrics cannot be computed without rasterization and the client must have the metrics before it can figure out how to position them. With a hundred (or so) bitmapped glyphs, the choice of where to store the fonts is largely irrelevant; either side would work equally well and centralizing them within the display server doesn't seem like the wrong solution. > server-side font handling: >most memory efficient >most network bandwidth efficient Actually, server-side font handling has neither of these benefits -- I've measured the network traffic generated by client-side fonts and have found that for typical modern applications, the trade off of transmitting some of the bitmaps vs transmitting all of the metrics is a wash. And that's when transmitting 8bpp alpha maps instead of 1bpp glyphs. As for memory, the storage requirements are equivalent -- the server must hold metrics and glyph data and the client must hold metrics. Add in incremental rasterization and the memory savings are clearly in favor of client-side rasterization. The one significant savings available for server-side rasterization is in CPU time. Sharing the cost of rasterizing glyphs is trivial when the server does the work and rather hard when done in the client. There are mechanisms in the Render extension to make this possible, but I don't have any plans to take advantage of them. > client-side font handling: >fastest way to get new features in To some extent; this just means that clients are in control of their fate. Place fonts in the X server and you can add features to *all* applications in one place. In a world without shared libraries, this is the one way to share code improvements. > the X server currently renders the entire set of characters which uses a > lot of server memory (anyone know if Xfs does incremental rasterization?). > This can be fixed (and should be fixed) It really can't be fixed -- the entire set of metrics must be delivered to the client before a single glyph can be drawn, the only way to compute metrics is to rasterize the glyphs. It would take a change in the protocol and an application-visible change in Xlib to make this possible. > I don't know whether Keith directly considered this issue when he designed > Xft or just thought "I can make a big improvement in X fonts and get it > into the users hands (without a protocol change)". Juliusz Chroboczek and Raph Levien made the suggestion to eliminate server-side fonts during the Render extension design and it was an epiphany for me -- I'd been struggling with these issues and suddenly they all just disappeared. > Xft is relatively memory efficient since apps > only generate per-glyphs metrics for the glyphs > they actually use and (assuming I understand this) > the glyphs at the server are shared. The Xft API also allows it to discard infrequently used metrics and glyphs so that memory usage can be controlled very tightly. A small change in the API will permit it to do the same with the underlying FreeType face. The X server actually shares *all* identical glyphs -- it has a single giant pool of glyphs that all clients and all glyphsets (fonts) reference. Keith PackardXFree86 Core TeamSuSE, Inc. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Kaixo!
On Thu, Nov 29, 2001 at 04:21:55PM +, Juliusz Chroboczek wrote:
> There are three reasons why you may want to use a FS:
>
> (i) centralisation of font files (better done with NFS IMHO);
> (ii) cases where the X server doesn't have a filesystem handy (not
>an issue for a default RedHat install);
> (iii) workaround for the server hang during rasterisation of large fonts.
There are other reasons too:
(iv) easier to automatically manage (automatically editing the X11 config
file is bad and dangerous; the xfs config file is much simpler)
(v) (maybe obsolete now) if the server is not multithreaded, it was better
to use a font server, as rasterization of a large font didn't freeze
the whole X, but only the program requesting that font, until the
rasterization ends.
I think (v) is the reason why use of a font server was a good thing in the
past. Reason (iv) is why it is done by default in Mandrake Linux (so adding
and removing fonts, either trough pre/post install scripts of font rpm packages
or through a user interactive program to install/remove fonts, is much
easier and less risky than messing with the X11 config file; also it allows
to have a same font config for both real X11 server and Xnest, which don't
use the default XF86Config file it seems, but has a hardwired fontpath;
by changing i nthe sources that hardwired fontpath to use the fontserver then
Xnest has by default the same font config as the standard X server; and
that is very useful; otherwise you need to manually define the fontpath
each time Xnest is launched.
> What bothers me is that you should present your choice as being the
> standard way of doing things -- what it is not, being merely a quick
> workaround for a problem that your predecessors were not willing to
> fix. While this may be a suitable trade-off for RedHat, it should not
> be presented as anything more than a quick workaround.
I don't know for Red Hat; but at lest for Mandrake that is not the reason
(if the font server crashes then the X server ends crashing too, usually;
so it doesn't change the stability to use a font server or not); the reason
is that having font config inside X11 config is bad (that was ok at several
years ago, when there were few fonts used, and almost never changed; nowadays
people has lots of fonts available and want to install and use them).
Note that Xft has its own config handling of fonts; without messing with
XF86Config{,-4}, so use of Xft is ok without the need of an "Xft-server"
similar to a font server.
In other words, if there were a possibility to use an external config file
for font handling done by the X server (maybe a special fontpath
like "config:/etc/X11/somefile" ), then I would be happy to drop default use
of xfs and use that feature instead.
--
Ki ça vos våye bén,
Pablo Saratxaga
http://www.srtxg.easynet.be/PGP Key available, key ID: 0x8F0E4975
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
How to move forward with fonts on X is a worthy discussion and I'm glad to see people thinking about it. I'd like to add a bit of input but from a different perspective. There has been a lot of discussion about X fonts recently in the mozilla world. This has caused me to look at X fonts from many directions. X fonts are currently lag fonts on the Mac and Microsoft Windows. I believe that this is directly caused by the choice to put font handling on the X server. The choice to put X font handling on the server as opposed to the client has some advantages (feel free to add more): sharing a common resource => memory savings the pixels are at the X server => minimal network bandwidth The choice to put X font handling on the server as opposed to the client has some disadvantages (feel free to add more): New font types require a X server (or X font server) upgrade which means it takes a long time for it to propagate on to users desktops since upgrading one's X server (or font server) is not commonly done except when the OS is upgraded or when a user gets a new system. It is hard to get new font information such as TrueType's GSUB, GPOS table down to the client. Any efficient way basically requires a X protocol upgrade/change. Changing the X protocol will take a long time since it requires people to agree on the protcol change and then the X servers in the field to be upgraded. It is hard to get the fonts to the printer. This is an area where X has lacked for a long time. >From my perspective the client-side vs server-side font choice boils down to: server-side font handling: most memory efficient most network bandwidth efficient client-side font handling: fastest way to get new features in While I said that server-side font handling is most memory efficient this is not always the case. If an app wants one large glyph (or one CJK glyph) the X server currently renders the entire set of characters which uses a lot of server memory (anyone know if Xfs does incremental rasterization?). This can be fixed (and should be fixed) but even when it is fixed it will take a while for the bulk of users to see the benefit because it is on the server side and requires a X server upgrade. While I said that server-side font handling is most network bandwidth efficient this is not always the case. If an app want one glyph from a font with a large amount of glyphs (think Unicode fonts) the X server currently has to send the per-glyph metrics for the entire set of characters (1). I don't know whether Keith directly considered this issue when he designed Xft or just thought "I can make a big improvement in X fonts and get it into the users hands (without a protocol change)". Either way I agree with his choice to have Xft do client side rendering. It allows new features to get into the field without requiring a server upgrade every time a new feature comes along. I believe that Xft's choice to do client-side font handling will lead to a vast improvment in X fonts over the next few years. A couple of things to note about Xft: Xft uses the Xrender extension to draw which give relatively good network performance since Xft/Xrender does require the glyphs to be sent up to the server (once) but Xft does not require the per-glyph metrics to be sent down from the server to the client. Xft is relatively memory efficient since apps only generate per-glyphs metrics for the glyphs they actually use and (assuming I understand this) the glyphs at the server are shared. -- Brian Stell Notes: 1: There si a trick an app can do using XLFD to workaround downloading the entire per-glyphs metrics for a font. This trick involves modifing the font XLDF name to specify a subset of glyphs. This can only work if "an app knows ahead of time what characters it needs". While this could be true for simple display programs it cannot be true for work processors. It also cannot be true for browsers which start displaying the page before the entire page is received (makes slow modem display tolerable). ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed 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 using a font server makes MH> sense, and those where it probably makes more sense to use the X MH> server itself. There are three reasons why you don't want to use a FS: (i) complicated configuration; (ii) fragility (much improved by Keith in 4.1); (iii) memory usage (all fonts held twice). There are three reasons why you may want to use a FS: (i) centralisation of font files (better done with NFS IMHO); (ii) cases where the X server doesn't have a filesystem handy (not an issue for a default RedHat install); (iii) workaround for the server hang during rasterisation of large fonts. As far as I am aware, the only reason why RedHat use a font server is (iii). What bothers me is that they use a font server by *default*, meaning that you get all users to pay the price, even those who do not use large fonts. It should be noted that the use of a FS is a workaround. A cleaner solution would be to use the mechanisms already present in the X server to prevent the hang from happening (tricky, but definitely doable -- in fact, the data structures in the freetype backend were designed with this in mind). An even better solution is to implement lazy glyph rasterisation, which is exactly what Keith is doing with Xft. What bothers me is that you should present your choice as being the standard way of doing things -- what it is not, being merely a quick workaround for a problem that your predecessors were not willing to fix. While this may be a suitable trade-off for RedHat, it should not be presented as anything more than a quick workaround. >> Yours is a RedHat-specific reply. Debian do things more reasonably, >> and don't require a font server by default. MH> I don't consider that a fair statement at all. It implies that MH> using a font server, is unreasonable, It is my opinion that using a font server *by default* in a general-purpose distribution is not reasonable. MH> Distro politics [...] This has nothing to do with distro politics. RedHat have made a technical choice in an area that I am intimately familiar with that I believe not to be reasonable. I do not think that publicly disagreeing with a choice made by RedHat amount to indulging in distro politics. >> P.S. Mike, sorry for the out-of-context quoting. I know it's not >> fair, but it was just too tempting. MH> If you agree, that it was not fair, then why bring it up at all? My out-of-context quoting was not fair. The comment above did not apply to the text of my reply. Regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
On Tue, 27 Nov 2001, Bashar Asad wrote: >> Dear Bashar Asad, >> I have frequently had this problem. The most common reason was that my >> disk space was very low and the xfs service in my distribution was not >> able to make its lockfiles and so xfs did not start up. >> Please check you disk space and stale lock files. >> al_shopov Yes, I have seen a few reports of that also. I think if it doesn't already, perhaps xfs should have some code added to detect low disk space situations, and fail gracefully, logging the reason to syslog. That would perhaps help users to discover a solution faster in similar situations. >>> Looks to me like you don't have a running fontserver. Start up >>> xfs, and it should be fine. >>> >>> I see people with this common problem a lot. In Red Hat Linux, >>> this would be done by: "service xfs start" however I'm not sure >>> what the Debian GNU/Linux syntax is for doing so. Could someone >>> let me know so I can give more specific info in the future to >>> Deb'ers? [SNIP] >Thanks guys, >I got it running, my xfs, but lacked the right fonts so I installed and >reinstalled a bunch of them ;) and now its running fine Good to hear. If you have any other problems, feel free to drop by #xfree86 on irc.openprojects.net for real-time help. Take care, TTYL -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
On 26 Nov 2001, Juliusz Chroboczek wrote: >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. I don't consider that a fair statement at all. It implies that using a font server, is unreasonable, and that somehow because Red Hat Linux uses a font server by default, we are also unreasonable. Very opinionated. There are both circumstances where using a font server makes sense, and those where it probably makes more sense to use the X server itself. >MH> I see people with this common problem a lot. In Red Hat Linux, > >Your predecessors at RedHat have chosen to unconditionally rely on a >font server, a decision which I personally disagree with. While they >may have had good reasons to do so, I have had it explained to me by those who made those decisions, and have discussed it with various people in the community as well. The font server can handle multiple requests simultaneously whereas the X server can not. The X server can end up blocking for long periods of time, depending on the fonts being used, and the complexity of the glyps, leading to poor interactive performance. >you should not assume that this is the only possible setup. I don't assume this is the only setup. It is a common setup, and IMHO on modern computers, it is the setup I believe to be more suitable. Both using a font server and not using one are "reasonable". And since it is open source software, one is free to decide for themself wether they use the font server or not on their systems. The OS vendor on the other hand, requires a default. We have chosen the default to use a font server, in order to provide good interactive response to all of our users by default, including international users who use large glyph sets, which magnify the issue. Occasional or constant jerky mouse movements when using XFree86 without a font server is one of the signs of this problem occuring. The only disadvantage that I know of to using a font server, is a slight amount of wasted memory due to some duplication. >P.S. Mike, sorry for the out-of-context quoting. I know it's not > fair, but it was just too tempting. If you agree, that it was not fair, then why bring it up at all? I was legitimately trying to help a Debian user. Trying to provoke a flamewar when someone is trying to be helpful to someone else is hardly what I would consider to be in the community spirit. I spend a lot of my own non-work personal time on #xfree86 on irc.openprojects.net helping XFree86 users. The channel is mostly filled by Debian GNU/Linux and Slackware regulars, and 80-90% of the traffic is Debian GNU/Linux users. Since I don't run Debian GNU/Linux, I can only help people mostly with things that are non-distribution specific. The open source community IMHO is about working together with each other to promote open source. Not wether you drive a Ford Truck or a Chevy. When distribution idealogy issues get in the way, it causes a breakdown of the cohesion of our community. If your comments above were said in jest, then perhaps I've taken them too seriously. I only say these things however, because when I communicate with the community, I don't discriminate between a Red Hat Linux user, a Debian GNU/Linux user, a Mandrake user, Slackware, *BSD, etc.. I have my preferences, and respect theirs. We're all using open source, and that is what it is all about. Sadly, while _most_ of the help I offer out, at least on IRC, is to people _not_ using Red Hat Linux, I get the _most_ amount of negative reactions from people who are also the ones I am trying to help. It makes me wonder just how much of the community is _truely_ serious about working _together_ and who all treat it as just fancy words to use against each other for political reasons. Nonetheless... I'll still be there tomorrow for all the Deb'ers who frequent #xfree86, and anyone else, and I welcome yourself and anyone else to join me there too. Lots of people come looking for help, and there aren't a lot of people outputting answers currently. It would be nice to have a Debian GNU/Linux expert frequent the channel. Distro politics are not at all ontopic in the channel however, so remember to keep it clean in the melting pot. ;o) Take care, TTYL -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___
Re: [Fonts]Help with fixed fonts
on 27/11/01 11:55 AM, Alexander Shopov at [EMAIL PROTECTED] wrote: > Dear Bashar Asad, > I have frequently had this problem. The most common reason was that my > disk space was very low and the xfs service in my distribution was not > able to make its lockfiles and so xfs did not start up. > Please check you disk space and stale lock files. > al_shopov > > On ??, 2001-11-25 at 03:25, Mike A. Harris wrote: >> On Sun, 25 Nov 2001, Bashar Asad wrote: >> >>> Date: Sun, 25 Nov 2001 02:43:45 +0300 >>> From: Bashar Asad <[EMAIL PROTECTED]> >>> To: [EMAIL PROTECTED] >>> Content-Type: text/plain; charset="US-ASCII" >>> List-Id: XFree86 Font List >>> Subject: [Fonts]Help with fixed fonts >>> >>> Hello, >>> Am getting this error message when running startx on my debian machine am >>> using xfree86 ver 4.1.0 >>> I think the top stuff is fine except the fixed font thing...I really don't >>> know what to do >>> >>> (**) Generic Mouse: Protocol: "ImPS/2" >>> (**) Generic Mouse: always reports core events >>> (EE) xf86OpenSerial: Cannot open device /dev/input/mice >>>No such device. >>> (EE) Generic Mouse: cannot open input device >>> (EE) PreInit failed for input device "Generic Mouse" >>> (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) >>> >>> Could not init font path element unix/:7100, removing from list! >>> >>> Fatal server error: >>> could not open default font 'fixed' >> >> Looks to me like you don't have a running fontserver. Start up >> xfs, and it should be fine. >> >> I see people with this common problem a lot. In Red Hat Linux, >> this would be done by: "service xfs start" however I'm not sure >> what the Debian GNU/Linux syntax is for doing so. Could someone >> let me know so I can give more specific info in the future to >> Deb'ers? >> >> Thanks in advance. >> TTYL >> >> >> -- >> -- >> Mike A. Harris Shipping/mailing address: >> OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, >> XFree86 maintainer Ontario, Canada, P6C 5B3 Thanks guys, I got it running, my xfs, but lacked the right fonts so I installed and reinstalled a bunch of them ;) and now its running fine -- Bashar Asad /*if one wants to be successful, one must think; one must think until it hurts. One must worry a problem in one's mind until it seems there cannot be another aspect of it that hasn't been considered */ Lord Thomson of Fleet >> Red Hat Inc.Phone: (705)949-2136 >> http://www.redhat.com ftp://people.redhat.com/mharris >> Red Hat XFree86 mailing list: [EMAIL PROTECTED] >> General open IRC discussion:#xfree86 on irc.openprojects.net >> -- >> >> ___ >> Fonts mailing list >> [EMAIL PROTECTED] >> http://XFree86.Org/mailman/listinfo/fonts > > > ___ > Fonts mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/fonts ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
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 a font server, a decision which I personally disagree with. While they may have had good reasons to do so, you should not assume that this is the only possible setup. To answer the OP's question: the error message says that the server was not able to find the default font. Most probably, the problem is with the font path being incorrect. Assuming you are using a font-server-less setup (as you should): - locate the fixed font on your system, which is usually in /usr/X11R6/lib/X11/fonts/misc/ (check fonts.dir); - add this directory to a FontPath statement in your XF86Config. If your installation is hosed, it may very well be that there is no fixed font on the system; in that case, you should install the relevant font packages. For more information, please see the README.fonts document included with the XFree86 distribution. This document assumes a font server-less installation throughout; if, for some reason, you insist on running a font server, you are pretty much on your own. Hope this helps, Juliusz P.S. Mike, sorry for the out-of-context quoting. I know it's not fair, but it was just too tempting. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Dear Bashar Asad, I have frequently had this problem. The most common reason was that my disk space was very low and the xfs service in my distribution was not able to make its lockfiles and so xfs did not start up. Please check you disk space and stale lock files. al_shopov On íä, 2001-11-25 at 03:25, Mike A. Harris wrote: > On Sun, 25 Nov 2001, Bashar Asad wrote: > > >Date: Sun, 25 Nov 2001 02:43:45 +0300 > >From: Bashar Asad <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Content-Type: text/plain; charset="US-ASCII" > >List-Id: XFree86 Font List > >Subject: [Fonts]Help with fixed fonts > > > >Hello, > >Am getting this error message when running startx on my debian machine am > >using xfree86 ver 4.1.0 > >I think the top stuff is fine except the fixed font thing...I really don't > >know what to do > > > >(**) Generic Mouse: Protocol: "ImPS/2" > >(**) Generic Mouse: always reports core events > >(EE) xf86OpenSerial: Cannot open device /dev/input/mice > >No such device. > >(EE) Generic Mouse: cannot open input device > >(EE) PreInit failed for input device "Generic Mouse" > >(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) > > > >Could not init font path element unix/:7100, removing from list! > > > >Fatal server error: > >could not open default font 'fixed' > > Looks to me like you don't have a running fontserver. Start up > xfs, and it should be fine. > > I see people with this common problem a lot. In Red Hat Linux, > this would be done by: "service xfs start" however I'm not sure > what the Debian GNU/Linux syntax is for doing so. Could someone > let me know so I can give more specific info in the future to > Deb'ers? > > Thanks in advance. > TTYL > > > -- > -- > Mike A. Harris Shipping/mailing address: > OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, > XFree86 maintainer Ontario, Canada, P6C 5B3 > Red Hat Inc.Phone: (705)949-2136 > http://www.redhat.com ftp://people.redhat.com/mharris > Red Hat XFree86 mailing list: [EMAIL PROTECTED] > General open IRC discussion:#xfree86 on irc.openprojects.net > -- > > ___ > Fonts mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/fonts ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
on 25/11/01 4:25 AM, Mike A. Harris at [EMAIL PROTECTED] wrote: > On Sun, 25 Nov 2001, Bashar Asad wrote: > >> Date: Sun, 25 Nov 2001 02:43:45 +0300 >> From: Bashar Asad <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Content-Type: text/plain; charset="US-ASCII" >> List-Id: XFree86 Font List >> Subject: [Fonts]Help with fixed fonts >> >> Hello, >> Am getting this error message when running startx on my debian machine am >> using xfree86 ver 4.1.0 >> I think the top stuff is fine except the fixed font thing...I really don't >> know what to do >> >> (**) Generic Mouse: Protocol: "ImPS/2" >> (**) Generic Mouse: always reports core events >> (EE) xf86OpenSerial: Cannot open device /dev/input/mice >>No such device. >> (EE) Generic Mouse: cannot open input device >> (EE) PreInit failed for input device "Generic Mouse" >> (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) >> >> Could not init font path element unix/:7100, removing from list! >> >> Fatal server error: >> could not open default font 'fixed' > > Looks to me like you don't have a running fontserver. Start up > xfs, and it should be fine. > > I see people with this common problem a lot. In Red Hat Linux, > this would be done by: "service xfs start" however I'm not sure > what the Debian GNU/Linux syntax is for doing so. Could someone > let me know so I can give more specific info in the future to > Deb'ers? > > Thanks in advance. > TTYL > Hello, I started the xfs server and in debian I did /etc/init.d/xfs restart|start And the server started but the problem is the same except the line "Could not init font path element unix/:7100, removing from list!" Is not in the error messages so I guess that part is fixed...the it still get Fatal server error: could not open default font 'fixed' thanks ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
On Sun, 25 Nov 2001, Bashar Asad wrote: >Date: Sun, 25 Nov 2001 02:43:45 +0300 >From: Bashar Asad <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset="US-ASCII" >List-Id: XFree86 Font List >Subject: [Fonts]Help with fixed fonts > >Hello, >Am getting this error message when running startx on my debian machine am >using xfree86 ver 4.1.0 >I think the top stuff is fine except the fixed font thing...I really don't >know what to do > >(**) Generic Mouse: Protocol: "ImPS/2" >(**) Generic Mouse: always reports core events >(EE) xf86OpenSerial: Cannot open device /dev/input/mice >No such device. >(EE) Generic Mouse: cannot open input device >(EE) PreInit failed for input device "Generic Mouse" >(II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE) > >Could not init font path element unix/:7100, removing from list! > >Fatal server error: >could not open default font 'fixed' Looks to me like you don't have a running fontserver. Start up xfs, and it should be fine. I see people with this common problem a lot. In Red Hat Linux, this would be done by: "service xfs start" however I'm not sure what the Debian GNU/Linux syntax is for doing so. Could someone let me know so I can give more specific info in the future to Deb'ers? Thanks in advance. TTYL -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
