On 31 Jan 2009, at 14:46, cage wrote: > I am having a strange problem with courier font in fltk (GNU/Linux). > > Apparently the appereance of a string rendered on screen with > courier (FL_COURIER) do not even resemble the same of > the standard postscript font, is this ok from the FLTK POV? > > Here you can find a comparision (http://www.autistici.org/interzona/ > bug.png) the framed strings are, respectively > helvetica and courier from a screenshot of a fltk app, while the > bottom one have been gotten from a generated > postscript file (helvetica and couriere again via libplot). > > This is a big problem when i want to export formatted text because > the two font do not share the same height and > width. > > Is this a fltk bug or maybe it is my fault? > > Please feel free to ask for more information!
Rendering of fonts on displays is an area that frequently throws up difficulties, and there is a long (and often painful!) history of people struggling with this. Indeed, one of the reasons PDF is the way it is, is because there was such a need for a way to render documents so they looked more or less the same wherever they were rendered... Returning to your question, however: - What distro are you using? - Do you know what fonts it actually has installed? - What font mapping is the font server doing? - Which version of fltk are you using? - Is fltk built with XFT support enabled? Looking at your png, it is clear that the two rendering engines have used completely different fonts to render the text in the images. Consider the two "courier" examples; look at the letter "l", and see that the glyphs are quite different. Then observe that the libplot version has used a serif font, whereas the fltk version is not. Similarly, the two Helvetica examples, on close inspection, are clearly not the same font at all. Also, it appears very much as if the libplot version has made an attempt at anti-aliasing, whist the fltk version has not (if fltk is built with XFT enabled, I would expect it to be anti-aliased too.) Is this a bug? No, probably not - if you use a catch-all name like "courier", the font engine will search through the installed fonts to find a font that it thinks is a suitable match, and use that. However, it is not certain that any two renderer's will make the same choice, so you can get quite different results. If you specify the full name of the font file, to both renderer's, you may be able to get results that are more similar. It is probably worth your while running the fltk font demo from the test folder and checking to see which fonts you actually have - you may be able to see which one the fltk rendering is falling back on when you request "courier", and so forth. Now, another thing that catches people out, is that fltk attempts to specify font sizes in display pixels (since it is a display oriented toolkit) but the majority of applications (even display oriented ones) tend towards specifying font sizes in points (or some interpretation thereof) so this can results in some noticeable difference in size on the display - 12-points is seldom the same size as 12-pixels... This is discussed in the fltk docs, IIRC. And this will vary with display DPI and etc., of course. Some experimentation my be required to find out what scaling works best for your application. So, I think if you make the two toolkits select the same actual underlying font, and adjust the sizes to suit, you will be able to make the text more similar in the two outputs. But getting any two different toolkits to render text in a pixel-identical way is *hard* so you probably do not want to go there! Hope that helped, -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
