(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available?
Note that my font knowledge is quite minimal
Context When I installed our product on a clean Red Hat Enterprise Linux 3 test machine it looked relatively acceptable. However on my own development machine (again RHEL3) for several texts the font was too large and overflowed the area that had been allocated for it. Then when I installed on Mandrake 10.0 I noticed the same large fonts.
So I dug.
On my machine (and probably on the Mandrake too; I don't know since I've trashed it) OpenOffice.org is installed. It installs /usr/share/fonts/openoffice, containing Vera*.ttf.
As an example the Splash screen asks for an Arial font. My development machine runs through the fonts it knows about and selects the Bitstream Vera Sans, which is not a good match.
The test machine has no ttf files to work from and so it reverses the Helvetica-Arial substitution (Hm!!! poor registry setup, I reckon) and performs a match for a Helvetica font and finds a much more acceptable font.
So it seems to me that merely because OpenOffice.org has installed a couple of ttf fonts my development machine will select from a small list of ttf fonts and ignore a large list of x11 fonts.
Am I correct? What should we do? Get the font matching logic to look at both the sets of fonts? Or add some sort of "Ignore these fonts" list in the Wine fonts area?
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available?
Yes that's right, and also intentional. It's basically impossible to do proper font support with server side fonts, so if we have any fonts we can use on the client side then we'll do client side rendering.
What should we do? Get the font matching logic to look at both the sets of fonts? Or add some sort of "Ignore these fonts" list in the Wine fonts area?
If you really want to disable client side font rendering in the x11drv you can do so by adding two keys to the [x11drv] section of the config file:
; Use the Render extension to render client side fonts (default "Y") "ClientSideWithRender" = "N" ; Fallback on X core requests to render client side fonts (default "Y") "ClientSideWithCore" = "N" ; Set both of the previous two to "N" in order to force X11 server side fonts
On January 18, 2005 03:00 pm, Huw D M Davies wrote:
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available?
Yes that's right, and also intentional. It's basically impossible to do proper font support with server side fonts, so if we have any fonts we can use on the client side then we'll do client side rendering.
What should we do? Get the font matching logic to look at both the sets of fonts? Or add some sort of "Ignore these fonts" list in the Wine fonts area?
If you really want to disable client side font rendering in the x11drv you can do so by adding two keys to the [x11drv] section of the config file:
; Use the Render extension to render client side fonts (default "Y") "ClientSideWithRender" = "N" ; Fallback on X core requests to render client side fonts (default "Y") "ClientSideWithCore" = "N" ; Set both of the previous two to "N" in order to force X11 server side fonts
I'm obviously misunderstanding something and not communicating effectively (probably because I don't understand the intricacies of the area), but the above doesn't help me.
My problem is very simple. When I ADD openoffice, increasing the number of fonts available, I get a worse display that if I didn't.
Here, I think, is the relevant portion of the two traces. trace:font:WineEngInit trace:font:WineEngInit FreeType version is 2.1.4 trace:font:ReadFontDir Loading fonts from "/home/medbi01/.wine/dosdevices/c:/windows/fonts" trace:font:load_fontconfig_fonts fontconfig: /usr/share/fonts/default/Type1/n022004l.pfb ... trace:font:load_fontconfig_fonts fontconfig: /usr/X11R6/lib/X11/fonts/Type1/c0419bt_.pfb
+++ This is found on the machine with openoffice
trace:font:load_fontconfig_fonts fontconfig: /usr/share/fonts/openoffice/Vera.ttf trace:font:AddFontFileToList Loading font file "/usr/share/fonts/openoffice/Vera.ttf" index 0 trace:font:AddFontFileToList fsCsb = 00000001 00000000/800000af 1000204a 00000000 00000000 trace:font:AddFontFileToList Added font L"Bitstream Vera Sans" L"Roman" ... trace:font:CreateFontIndirectW (19 0 0 0 22 3 2 0 0) L"Arial" Bold => 0x12c6 trace:font:WineEngCreateFontInstance L"Arial", h=19, it=0, weight=700, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance not in cache +++ On the openoffice machine trace:font:WineEngCreateFontInstance substituting L"Arial" -> L"Helvetica" trace:font:WineEngCreateFontInstance Chosen: L"Bitstream Vera Sans" L"Bold" trace:font:WineEngGetFontData font=0x40079fa8, table=584d4456, offset=00000000, buf=0x493ef470, cbData=6 trace:font:WineEngGetFontData Can't find table 56444d58. trace:font:WineEngCreateFontInstance caching: gdiFont=0x40079fa8 hfont=0x12c6 --- On the machine without trace:font:WineEngCreateFontInstance No fonts installed trace:font:X11DRV_SelectFont hdc=0x74, hfont=0xda2 trace:font:X11DRV_SelectFont gdiFont = (nil) trace:font:XFONT_UnAlias found alias 'Arial'->Helvetica' trace:font:X11DRV_SelectFont hfont=0xda2 trace:font:XFONT_MatchDeviceFont (0) 'Helvetica' h=19 weight=700 trace:font:XFONT_MatchDeviceFont found facename 'Helvetica' ...
So it seems to me that the problem is not to do with whether we do client or server side on the x11drv; it is whether we even get to the x11drv.
Can you think of anything else that might work?
On January 18, 2005 03:00 pm, Huw D M Davies wrote:
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available?
Yes that's right, and also intentional. It's basically impossible to do proper font support with server side fonts, so if we have any fonts we can use on the client side then we'll do client side rendering.
But surely in my case it's still client-side rendering; it's just that it isn't the freetype that is doing it. (NB I haven't the faintest idea what I am talking about, of course, not knowing much about freetype)
Basically what is frustrating me here is that a client's perfectly good Enterprise level operating system comes with a plethora of fonts, only a couple of which are ttf and our system selects from that small list instead of the much larger list (which presumably freetype supports but we don't) and there is no way to stop it. The only option available seems to me to be to install (illegally?) the appropriate Microsoft ttf fonts (e.g. Arial).
Is there really no way of getting over this problem short of removing the freetype.
On Wed, Jan 19, 2005 at 05:58:59PM -0800, Bill Medland wrote:
On January 18, 2005 03:00 pm, Huw D M Davies wrote:
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available?
Yes that's right, and also intentional. It's basically impossible to do proper font support with server side fonts, so if we have any fonts we can use on the client side then we'll do client side rendering.
But surely in my case it's still client-side rendering; it's just that it isn't the freetype that is doing it. (NB I haven't the faintest idea what I am talking about, of course, not knowing much about freetype)
No, when there are no TrueType fonts then Wine lets the XServer do the font rendering and thus uses the fonts that the XServer knows about. This is server-side rendering. Unfortunately the X11 protocol doesn't give nearly enough control over the rendering to emulate the win32 api font capabilities, so we really try to use client-side font rendering whenever possible.
Basically what is frustrating me here is that a client's perfectly good Enterprise level operating system comes with a plethora of fonts, only a couple of which are ttf and our system selects from that small list instead of the much larger list (which presumably freetype supports but we don't) and there is no way to stop it.
At some point we should add support of Type1 PostScript fonts and this may help.
The only option available seems to me to be to install (illegally?) the appropriate Microsoft ttf fonts (e.g. Arial).
If you really want the output to look like Windows then this is the only solution. I suggest you read the EULA of these fonts.
Huw.
On January 20, 2005 03:31 am, Huw D M Davies wrote:
On Wed, Jan 19, 2005 at 05:58:59PM -0800, Bill Medland wrote:
On January 18, 2005 03:00 pm, Huw D M Davies wrote:
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
(Huw?)
Do I need to dig deeper to understand this or is there a defect in the logic. If there are ttf fonts available does that mean a poor ttf match will be selected even when a better x11drv font is available?
Yes that's right, and also intentional. It's basically impossible to do proper font support with server side fonts, so if we have any fonts we can use on the client side then we'll do client side rendering.
But surely in my case it's still client-side rendering; it's just that it isn't the freetype that is doing it. (NB I haven't the faintest idea what I am talking about, of course, not knowing much about freetype)
No, when there are no TrueType fonts then Wine lets the XServer do the font rendering and thus uses the fonts that the XServer knows about. This is server-side rendering. Unfortunately the X11 protocol doesn't give nearly enough control over the rendering to emulate the win32 api font capabilities, so we really try to use client-side font rendering whenever possible.
Basically what is frustrating me here is that a client's perfectly good Enterprise level operating system comes with a plethora of fonts, only a couple of which are ttf and our system selects from that small list instead of the much larger list (which presumably freetype supports but we don't) and there is no way to stop it.
At some point we should add support of Type1 PostScript fonts and this may help.
The only option available seems to me to be to install (illegally?) the appropriate Microsoft ttf fonts (e.g. Arial).
If you really want the output to look like Windows then this is the only solution. I suggest you read the EULA of these fonts.
No No No
I want it to look, after installing OpenOffice, the way it looked before I installed OpenOffice.
It works perfectly adequately for me (and for our clients, hopefully) when it doesn't try to use the few ttf fonts that it finds and simply falls back on the XServer. However your settings for the xlldrv section didn't seem to make a difference.
Huw.
On January 20, 2005 07:37 am, Bill Medland wrote:
On January 20, 2005 03:31 am, Huw D M Davies wrote:
On Wed, Jan 19, 2005 at 05:58:59PM -0800, Bill Medland wrote:
On January 18, 2005 03:00 pm, Huw D M Davies wrote:
On Tue, Jan 18, 2005 at 12:08:17PM -0800, Bill Medland wrote:
(Huw?)
However your settings for the xlldrv section didn't seem to make a difference.
My sincerest apologies, Huw. xlldrv is not quite the same as x11drv, is it? (I haven't the faintest idea how I mis-spelled it!!!)
BTW, Would adding Postscript handling handle pfb, pfa and pcf files? (I don't know font formats.)
-
Bill Medland -
Huw D M Davies