From: Arjen M. <arj...@wl...> - 2005-12-28 14:25:19
|
Hello, I am making considerable progress on the Windows platform: I have expanded the win3 driver with the ability to use the freetype library. I took most of the code for that from the wingcc driver but I had to make a few changes to plfreetype.c - a UNIX-specific include file and a UNIX-specific system function. I can solve those issues in a transparent way though. There are several other issues that need ironing out - such as the font translation table. So, it is not as straightforward as I hoped. I did run into a few oddities: - Example 2 causes a lot of complaints about the colour map - impossible to tell what, but I guess the extra colours needed for the antialiasing are the cause. - The freetype library can be turned on via -drvopt text=1 but then I do not see any text anymore ;). I presume this is due to the positioning of the text ... but does anyone have a hint? Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-12-29 07:29:47
|
Andrew Roach wrote: > > Hello Arjen, > > At 03:25 PM 28/12/2005 +0100, you wrote: > > > I did run into a few oddities: > > > > - Example 2 causes a lot of complaints about the > > colour map - impossible to tell what, but I > > guess the extra colours needed for the antialiasing > > are the cause. > > That is a problem with any driver using freetype sadly. What happened > was the cmap0 code was changed about a year or so ago to allow dynamic > changes to the colour map size, in a way which freetype was not ever > made aware. Freetype tweaks the cmap0 to get smoothing of colours, so > what happens is freetype takes most available colour slots away from > the cmap0 to get smoothing before the page initialises, then in the > case of example 2, it [example 2] wants to take some extra colour > slots to expand its depth, but after initialising the plot page, by > which time freetype has taken the free slots, so they are not > available to example 2, hence the error. If you turn off smoothing, > the error goes away. In reality this error would affect few if any > applications, and probably only example 02. Eventually I want to > change freetype with certain devices so that when there is a > truecolour display with in-built alpha-blending, the smoothing is done > a level above the driver rather than within plplot. It will also fix a > slightly annoying problem with the smoothed text plotting on top of > other areas of colour, and having the smoothing come out incorrectly. > Okay, i will ignore this matter then. Thanks for the explanation. > > - The freetype library can be turned on via -drvopt text=1 > > but then I do not see any text anymore ;). I presume this > > is due to the positioning of the text ... but does anyone > > have a hint? > > That one does not sound qute right to me. When the freetype library is > activated, the text should be rendered by freetype, and you should > still see it. Might be worth checking which font the system is > expecting. > It is working now - almost. I made a mistake with the scaling parameter for the interface to the freetype library. I now have text that is _almost_ drawn correctly. The issues that remain are: - when resizing the window, the scaling and positioning is not adjusted (easy to fix) - initially the text (I am talking of example 1 now) is slightly off course. The title appears too high and the symbols are not on the curve. This may be related to the first problem. - the symbols in example 1 are squares instead of circles if I turn on freetype. Is that foreseen? - example 24 shows a very messy picture which can not be recognised as a set of characters of any kind, but it stresses the font system to its limit, so I won't lie awake over it ... Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-12-29 16:22:38
|
On 2005-12-29 08:29+0100 Arjen Markus wrote: > > - example 24 shows a very messy picture which can not be recognised > as a set of characters of any kind, but it stresses the font system > to its limit, so I won't lie awake over it ... Are you following the instructions embedded in examples/c/x24c.c? You have to make sure that fonts are installed for every language on the flag, set the appropriate environment variables so those fonts are accessible from PLplot, then execute the example using -drvopt smooth=0. I suspect you forgot the last requirement. If you use default smoothing instead, the result looks extremely messy just like you described. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2005-12-30 07:28:54
|
"Alan W. Irwin" wrote: > > On 2005-12-29 08:29+0100 Arjen Markus wrote: > > > > > - example 24 shows a very messy picture which can not be recognised > > as a set of characters of any kind, but it stresses the font system > > to its limit, so I won't lie awake over it ... > > Are you following the instructions embedded in examples/c/x24c.c? > > You have to make sure that fonts are installed for every language on the > flag, set the appropriate environment variables so those fonts are > accessible from PLplot, then execute the example using -drvopt smooth=0. I > suspect you forgot the last requirement. If you use default smoothing > instead, the result looks extremely messy just like you described. > Alan, I certainly forgot that smooth=0 one. I am not sure about the available fonts - it is the mirkiest part of the whole thing, actually. Note: I copied the font translation table from the wingcc configuration and it seemed to work alright, but I have no idea if it really is appropriate. Well, my system is not customised for exotic fonts or anything, so I expect most Windows machines to have the same set. At least it is worth to try it with that extra flag. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-12-30 19:11:07
|
On 2005-12-30 08:28+0100 Arjen Markus wrote: > Alan, > > I certainly forgot that smooth=0 one. I am not sure about the available > fonts - it is the mirkiest part of the whole thing, actually. > > Note: I copied the font translation table from the wingcc configuration > and it seemed to work alright, but I have no idea if it really is > appropriate. > Well, my system is not customised for exotic fonts or anything, so I > expect > most Windows machines to have the same set. > > At least it is worth to try it with that extra flag. > To Arjen and Andrew (Roach): I think getting x24c to work on windows-based platforms is tremendously important since potentially there are a lot of users using those platforms who would like to make figure captions in their native (non-Western European) language. So I have made some further comments here to help you two with that goal. Arjen, if your device win3 is working correctly, then "./x24c -dev win3 -drvopt smooth=0" should generate the "Western European language" half of the flag exactly like http://plplot.sourceforge.net/examples/demo24.php) while the other half should be incorrect characters or blanks if you are just using default fonts. Is that the result you get now? Once you get that result, then the remaining font part should be straightforward but tedious. For each remaining non-Western European language on the flag you must find and install a good windows font for that language and inform PLplot at run-time where that special font is located on your system. However, before tackling that task for the bare windows platform I suggest you and Andrew do the same thing on Cygwin and MinGW first for the wingcc device since the run-time infrastructure is already (mostly) in place to support that. On Unix based systems environment variables are used to specify the location of special fonts at run time. Andrew, will you comment on that issue for the Cygwin, MinGW, DJGPP and bare windows platforms? I do know the first two have general support for environment variables, but I believe DJGPP and bare windows does not have that exact capability. Perhaps there is some other standard way on those platforms for the command-line user to communicate with executables? Note, plfreetype.c file has some conditional compile sections depending on WIN32 and MSDOS which might need to be changed so that environment variables can be used for at least Cygwin and MinGW to specify font information at run time. Once the two of you have found a good "exotic" windows font set to run x24c on the Cygwin and MinGW platforms using environment variables to specify the fonts, then you should be able to do something similar for the bare windows and DJGPP platforms for plfreetype-aware device drivers (such as win3 for bare windows) that are specific to those platforms. I am assuming here that some rough equivalent to environment variables exists for bare windows and DJGPP to allow command-line users to communicate with executables at run-time. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-01-02 07:34:41
|
"Alan W. Irwin" wrote: > > To Arjen and Andrew (Roach): > > I think getting x24c to work on windows-based platforms is tremendously > important since potentially there are a lot of users using those platforms > who would like to make figure captions in their native (non-Western > European) language. So I have made some further comments here to help you > two with that goal. > I tested it with smooth=0: that gave pretty much the same result as the demo picture, except for the Korean, Bengali (?) and perhaps the Chinese font (I do not remember whether that was missing too - the others certainly gave empty rectangles). I tried to put in code to correctly handle the window resizing, but that fails horribly at the moment. I have not had a chance to look into the cause yet. (Most probable: random pointer to the Freetype component in the pls structure). > Arjen, if your device win3 is working correctly, then "./x24c -dev win3 > -drvopt smooth=0" should generate the "Western European language" half of > the flag exactly like http://plplot.sourceforge.net/examples/demo24.php) > while the other half should be incorrect characters or blanks if you are > just using default fonts. Is that the result you get now? > Yes, as I said above. > Once you get that result, then the remaining font part should be > straightforward but tedious. For each remaining non-Western European > language on the flag you must find and install a good windows font for that > language and inform PLplot at run-time where that special font is located on > your system. However, before tackling that task for the bare windows > platform I suggest you and Andrew do the same thing on Cygwin and MinGW > first for the wingcc device since the run-time infrastructure is already > (mostly) in place to support that. > > On Unix based systems environment variables are used to specify the location > of special fonts at run time. Andrew, will you comment on that issue for > the Cygwin, MinGW, DJGPP and bare windows platforms? I do know the first > two have general support for environment variables, but I believe DJGPP and > bare windows does not have that exact capability. Windows does have support for environment variables but if I put it diplomatically, extensive use is not encouraged (the reasons are legion - I will not list them right now). > Perhaps there is some > other standard way on those platforms for the command-line user to > communicate with executables? Note, plfreetype.c file has some conditional > compile sections depending on WIN32 and MSDOS which might need to be changed > so that environment variables can be used for at least Cygwin and MinGW to > specify font information at run time. > Well, Windows encourages the use of the registry for many such more-or-less persistent pieces of information. The main problem: it is surrounded by an aura of awe - the registry is essential to the workings of the Windows OS. So, messing about with it is not recommended for people who do not what they are doing. > Once the two of you have found a good "exotic" windows font set to run x24c > on the Cygwin and MinGW platforms using environment variables to specify the > fonts, then you should be able to do something similar for the bare windows > and DJGPP platforms for plfreetype-aware device drivers (such as win3 for > bare windows) that are specific to those platforms. I am assuming here that > some rough equivalent to environment variables exists for bare windows and > DJGPP to allow command-line users to communicate with executables at > run-time. > Finding such fonts may not be a big issue, finding fonts that are freely available may be. I will keep you posted. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-01-04 09:20:26
|
> > > Finding such fonts may not be a big issue, finding fonts that are freely > available may be. I will keep you posted. > > Regards, > > Arjen As mentioned before, the freefont 2003 package is the way to go. Extract them from the debian package, since they are not available anymore on the main website. Put them in c:\windows\fonts and set 30 environment variables :) Or change the freetype.cf accordingly, so that also in Windows the Freefont is used (if available). Regards, Werner |
From: Arjen M. <arj...@wl...> - 2006-01-04 12:41:17
|
Werner Smekal wrote: > > > As mentioned before, the freefont 2003 package is the way to go. Extract > them from the debian package, since they are not available anymore on > the main website. Put them in c:\windows\fonts and set 30 environment > variables :) > > Or change the freetype.cf accordingly, so that also in Windows the > Freefont is used (if available). > Let me just mention a brief experiment I did before with two fonts I downloaded and _copied_ into the c:\windows\fonts directory: I changed the font list by setting two environment variables and saw that the Chinese text went from empty boxes to nothing. The Bengali text went from empty boxes to slightly fatter empty boxes. So there was some effect, but not the way I had anticipated/hoped for. The fonts did not show up in the list of available fonts for the character map utility. So that made me suspicious: you need to install fonts - you can not just copy them. Well, that defines the next step in this adventure :) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-01-04 18:19:34
|
On 2006-01-04 13:41+0100 Arjen Markus wrote: > The fonts did not show up in the list of available fonts for the > character map utility. So that made me suspicious: you need to > install fonts - you can not just copy them. That statement isn't actually correct for the current PLplot since all that is required is to get access to the font file. However, you do have to copy the font file to the correct windows font directory. According to plfreetype.c, that font directory is currently determined by looking at two separate directories and picking the first one that has arial.ttf in it. On the Unix side of things, the approach is only slightly more sophisticated; you are allowed to specify the font directory directly. Note, some tweaking of the conditional programming in plfreetype.c will probably be necessary to utilize our "Unix" font finding system for Cygwin and MinGW. We could modify both the windows and Unix font-finding systems to make them more sophisticated, but I don't think we should bother much with that. Instead, I think the proper approach is to use the fontconfig utility which is designed especially to find system fonts in the most general and intelligent way possible. fontconfig is the premier application for doing that on Linux systems, and it is also available on windows. If/when we switch to it, the above directory worries will be a thing of the past and instead of specifying font file names (e.g., "arial.ttf") we will be specifying font names that fontconfig understands (e.g., "Arial"). However, in order to use fontconfig you will have to do a full system install of the font (so that fontconfig is aware of it) rather than just simply copying it as now. I only understand what fontconfig does in overview. Thus, I hope some volunteer (especially from the windows side to make sure it really works there) will evaluate fontconfig in more detail then (assuming there are no showstoppers) go ahead and implement its use in conjunction with plfreetype.c. Of course, we will want to keep the present crude font directory and font file name system for those systems that don't have fontconfig installed. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2006-01-05 05:28:35
|
On 2006-01-04 13:41+0100 Arjen Markus wrote: >The fonts did not show up in the list of available fonts for the >character map utility. So that made me suspicious: you need to >install fonts - you can not just copy them. Actually, that is all you do need to install them; the OS monitors any changes to that directory and will automatically register a new font when copied into it. That it doesn't appear in the character map utility makes me wonder if it isn't a Windows compatible truetype font or, doesn't have a compatible charset mapping ? If you don't have the right charsets installed on windows (another thing entirely), fonts wont work. Usually a font lists multiple charsets in order of precedence, and then usually a generic one at the end to ensure they display, but strictly speaking, that isn't what they should do - if there isn't a compatible charset, they should not display. Those fonts you installed probably don't have a compatible windows charset mapping, which is why they don't turn up in the dialogs. At 10:17 AM 4/01/2006 -0800, you wrote: >That statement isn't actually correct for the current PLplot since all that >is required is to get access to the font file. However, you do have to copy >the font file to the correct windows font directory. According to >plfreetype.c, that font directory is currently determined by looking at two >separate directories and picking the first one that has arial.ttf in it. All that does is use fonts to work out if the user has a pre Win95 version of windows or post. In Windows, the actual directory never moves, so no real searching is needed. >We could modify both the windows and Unix font-finding systems to make them >more sophisticated, but I don't think we should bother much with that. With windows, for 99.999% of users (anyone still have win3.1 ???) you could even hard-wire it and do away with any searching at all. -Andrew |
From: Andrew R. <aro...@ya...> - 2005-12-31 02:24:30
|
>On Unix based systems environment variables are used to specify the= location >of special fonts at run time. Andrew, will you comment on that issue for >the Cygwin, MinGW, DJGPP and bare windows platforms? I do know the first >two have general support for environment variables, but I believe DJGPP and >bare windows does not have that exact capability. The environmental variables work (as under unix) on those platforms,=20 although there might be limitations depending on the actual OS being used=20 and how it is configured. > Perhaps there is some >other standard way on those platforms for the command-line user to >communicate with executables? For windows, the logical alternative would be to enter the font mappings=20 into the registry; however, environmental variables work exactly the same=20 way under windows and unix=85 you just set them a little differently -=20 accessing them is the same, so that probably isn't really a necessary step. > Note, plfreetype.c file has some conditional >compile sections depending on WIN32 and MSDOS which might need to be= changed >so that environment variables can be used for at least Cygwin and MinGW to >specify font information at run time. The conditionals in WIN32 and MSDOS are only to do with the font path,=20 which on Windows is always fixed, not the font names or mappings. -Andrew |
From: Alan W. I. <ir...@be...> - 2005-12-31 06:45:06
|
On 2005-12-31 12:24+1000 Andrew Roach wrote: > The conditionals in WIN32 and MSDOS are only to do with the font path, which > on Windows is always fixed, not the font names or mappings. OK. Thanks for clearing up my misunderstanding. So with environment variables available on all 4 windows-like platforms, it's possible the only barrier to x24c working correctly on those platforms is finding appropriate language fonts to install on windows. Have you been able to make any progress there? If you are having any trouble finding something suitable that most windows users would find easy to install, you could always fall back to using the special language fonts that x24c.c currently recommends for Linux platforms. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-01-02 07:41:46
|
"Alan W. Irwin" wrote: > > On 2005-12-31 12:24+1000 Andrew Roach wrote: > > > The conditionals in WIN32 and MSDOS are only to do with the font path, which > > on Windows is always fixed, not the font names or mappings. > > OK. Thanks for clearing up my misunderstanding. So with environment > variables available on all 4 windows-like platforms, it's possible the only > barrier to x24c working correctly on those platforms is finding appropriate > language fonts to install on windows. Have you been able to make any > progress there? > > If you are having any trouble finding something suitable that most windows > users would find easy to install, you could always fall back to using the > special language fonts that x24c.c currently recommends for Linux platforms. > I have no idea how "Linux fonts" would work on Windows, but I know one or two people who can help out with finding the appropriate fonts. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-01-02 17:52:48
|
On 2006-01-02 08:41+0100 Arjen Markus wrote: > I have no idea how "Linux fonts" would work on Windows... Well, windows fonts work fine on Linux (see http://linux.org.mt/article/ttfonts) so I think the reverse would be true as well. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-01-03 07:21:12
|
"Alan W. Irwin" wrote: > > On 2006-01-02 08:41+0100 Arjen Markus wrote: > > > I have no idea how "Linux fonts" would work on Windows... > > Well, windows fonts work fine on Linux (see > http://linux.org.mt/article/ttfonts) so I think the reverse would be true as > well. > I may be cynical, but the Linux community has much more to gain by maintaining compatibility with Windows, than the other way around. Anyway, the site "South Asia Language Resource" (http://salrc.uchicago.edu/resources/) has a lot of information on free and commerical fonts for Asian scripts. I have not been able to test any of them yet - I ran into a bizarre problem with the win3 driver (see another posting) - but it looks like there is plenty of material to choose from. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-01-03 08:49:42
|
On 2006-01-03 08:20+0100 Arjen Markus wrote: > "Alan W. Irwin" wrote: >> Well, windows fonts work fine on Linux (see >> http://linux.org.mt/article/ttfonts) so I think the reverse would be true as >> well. >> > > I may be cynical, but the Linux community has much more to gain > by maintaining compatibility with Windows, than the other way around. Your comment might be true for some cases but not for fonts where open standards exist that by definition can be used on any platform. See http://www.lorp.org/truetype/tthist.htm for some history of this. Because these standards exist, TrueType and Type 1 fonts developed on windows work fine on Linux and vice versa because the various platforms are following these well-defined open standards. You have to give MS credit; for font issues they have generally played fairly by sticking to open standards. This completely contrasts with the Office situation where MS avoids playing fairly by using a closed (and changing) format rather than the existing OpenDocument standard. If you would like to look at some extraordinarly well-written commentary about one man's attempt in the Massachusetts State government to address this important issue, I would strongly recommend reading Pamela Jones's GrokLaw blog, especially today's story at http://www.groklaw.net/article.php?story=20051230204255532 . Her closing sentence is a classic: "Incidents like the libel of Peter Quinn cost Microsoft business. Here's why: There's something in the human heart that utterly despises a bully." > > Anyway, the site "South Asia Language Resource" > (http://salrc.uchicago.edu/resources/) > has a lot of information on free and commerical fonts for Asian scripts. Hope that font resource works out for you once you are in a position to try it. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-01-03 09:29:48
|
"Alan W. Irwin" wrote: > > > Your comment might be true for some cases but not for fonts where open > standards exist that by definition can be used on any platform. See > http://www.lorp.org/truetype/tthist.htm for some history of this. Because > these standards exist, TrueType and Type 1 fonts developed on windows work > fine on Linux and vice versa because the various platforms are following > these well-defined open standards. You have to give MS credit; for font > issues they have generally played fairly by sticking to open standards. > Good to hear that. It does encourage me to look further into the matter. Some comments on the SALRC site made me a bit wary - comments about service packs and such, but those are probably more important when you need to deal with input as well as displaying these scripts. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-01-03 15:17:17
|
Hello all, I get the strangest error in a part of the win3 driver. It occurs in the WM_PAINT event to (re)draw the picture after for instance a resize of the window: ... #ifdef HAVE_FREETYPE FT_Data *FT=(FT_Data *)pls->FT; #endif ... case WM_PAINT ... #ifdef HAVE_FREETYPE if ( freetype ) { FILE *outf = fopen("aa", "w") ; /* fclose( outf ) ; */ fprintf( outf, "ft: %p\n", pls->FT ) ; fflush(outf); fprintf( outf, "x: %f\n", (float)dev->xScale ) ; fflush(outf); fprintf( outf, "y: %f\n", (float)dev->yScale ) ; fflush(outf); fprintf( outf, "ft: %p\n", FT ) ; fflush(outf); <==== The line in question! fclose( outf ); /* Commented out: to see where the crash occurs */ /* if ( dev->xPhMax > dev->yPhMax ) { FT->scale=1.0/dev->xScale; } else { FT->scale=1.0/dev->yScale; } FT->ymax=dev->yPhMax; */ } #endif ... break ; If I print the variable FT (via %p), the program crashes. If I leave out that line, all goes well (except for the position of Freetype text, unfortunately). I am astounded by this: can anyone tell me how to proceed? What is wrong? Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-01-04 09:08:37
|
Hi, sorry that I take part in this topic that late, but you should have a look at the wxWidgets driver - the freetype stuff is quite complete and also works in Windows. Mind also that you have to set the xdpi and ydpi variable, since (if set) they are used to calculate the size of the fonts if you resize the window (you have to set xdpi/ydpi if you resize the Window). Regarding the misplacement of fonts. I tried four different fonts. * Freefont from 2003 (http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=ttf-freefont) * Freefont from 2005 (http://savannah.nongnu.org/projects/freefont/) * Windows fonts (Arial, etc.) * Bitstream (free Gnome fonts, http://www.gnome.org/fonts/) The only fonts which are working satisfactory is the Freefont package from 2003, they are also most complete, regarding symbols and so on). So somehow the plplot-Freetype code is tweaked to work with the Freefont 2003 package. So it's no mistake on your part Arjen. This misplacement also happens on other platforms (Linux (if other fonts are used), Mac OSX). HTH, Werner PS: Regarding the bug below: I don't see why it should crash in this line, since even if the pointer is not initalized, it should show "0x0" or similar. You should use ddd to make sure, that it really crashed in this line. PPS: I'm not sure how win3 driver uses the xScale/yScale variables, but you have to adjust the wxWidgets/Freetype code maybe a little bit, depending on how the scale variables were used. Arjen Markus wrote: > Hello all, > > I get the strangest error in a part of the win3 driver. > It occurs in the WM_PAINT event to (re)draw the picture > after for instance a resize of the window: > > ... > #ifdef HAVE_FREETYPE > FT_Data *FT=(FT_Data *)pls->FT; > #endif > > ... > > case WM_PAINT > ... > #ifdef HAVE_FREETYPE > > if ( freetype ) { > FILE *outf = fopen("aa", "w") ; > /* fclose( outf ) ; */ > fprintf( outf, "ft: %p\n", pls->FT ) ; fflush(outf); > fprintf( outf, "x: %f\n", (float)dev->xScale ) ; fflush(outf); > fprintf( outf, "y: %f\n", (float)dev->yScale ) ; fflush(outf); > fprintf( outf, "ft: %p\n", FT ) ; fflush(outf); <==== > The line in question! > fclose( outf ); > > /* Commented out: to see where the crash occurs */ > > /* > if ( dev->xPhMax > dev->yPhMax ) { > FT->scale=1.0/dev->xScale; > } else { > FT->scale=1.0/dev->yScale; > } > FT->ymax=dev->yPhMax; > */ > } > #endif > ... > break ; > > If I print the variable FT (via %p), the program crashes. > If I leave out that line, all goes well (except for the position of > Freetype text, unfortunately). > > I am astounded by this: can anyone tell me how to proceed? What is > wrong? > > Regards, > > Arjen > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@wl...> - 2006-01-04 10:21:20
|
Werner Smekal wrote: > > Hi, > > sorry that I take part in this topic that late, but you should have a > look at the wxWidgets driver - the freetype stuff is quite complete and > also works in Windows. > > Mind also that you have to set the xdpi and ydpi variable, since (if > set) they are used to calculate the size of the fonts if you resize the > window (you have to set xdpi/ydpi if you resize the Window). > > Regarding the misplacement of fonts. I tried four different fonts. > > * Freefont from 2003 > (http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=ttf-freefont) > * Freefont from 2005 (http://savannah.nongnu.org/projects/freefont/) > * Windows fonts (Arial, etc.) > * Bitstream (free Gnome fonts, http://www.gnome.org/fonts/) > > The only fonts which are working satisfactory is the Freefont package > from 2003, they are also most complete, regarding symbols and so on). > > So somehow the plplot-Freetype code is tweaked to work with the Freefont > 2003 package. So it's no mistake on your part Arjen. This misplacement > also happens on other platforms (Linux (if other fonts are used), Mac OSX). > Hello, Werner, thanks for this advice. Hm, the fact that the Freefont from 2003 is no longer available directly makes me a bit wary: wouldn't that require users to delve into the archives? It would be far better if we can use any odd font without a problem. (There is some comment in the code about the height of the characters and the apparent mismatch about what was expected ... Maybe that is a clue?) > HTH, > Werner > > PS: Regarding the bug below: I don't see why it should crash in this > line, since even if the pointer is not initalized, it should show "0x0" > or similar. You should use ddd to make sure, that it really crashed in > this line. > Yes, I will probably need to go the debugger way for this. It is very odd though: if I do not include that line, printing FT as a pointer, all goes well. > PPS: I'm not sure how win3 driver uses the xScale/yScale variables, but > you have to adjust the wxWidgets/Freetype code maybe a little bit, > depending on how the scale variables were used. > I will have a look at the wxWidgets driver. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-01-04 11:09:19
|
> > thanks for this advice. Hm, the fact that the Freefont from 2003 is > no longer available directly makes me a bit wary: wouldn't that require > users to delve into the archives? It would be far better if we can > use any odd font without a problem. For the time being we (the plplot site) could provide a freefont 2003 zip, since they are free, this should be no problem at all. Even better, we could include the font into the plplot distribution, which would make plplot more "independent". But since all other fonts are displayed wrong, at the long run, the freetype code should be adjusted to work with the latest freefont and I think most other fonts should then also work ok. But I think most Linux distributions still use the freefont 2003 (e.g. debian, if they use it at all, since redhat enterprise ws 4 doesn't have it) and we therefore would break the Linux version of plplot. > > (There is some comment in the code about the height of the characters > and the apparent mismatch about what was expected ... Maybe that is > a clue?) I also think that this is the place to start. Regards, Werner |
From: Alan W. I. <ir...@be...> - 2006-01-04 18:38:31
|
On 2006-01-04 12:08+0100 Werner Smekal wrote: > But since all other fonts are displayed wrong, at the long run, the freetype > code should be adjusted to work with the latest freefont and I think most > other fonts should then also work ok. But I think most Linux distributions > still use the freefont 2003 (e.g. debian, if they use it at all, since redhat > enterprise ws 4 doesn't have it) and we therefore would break the Linux > version of plplot. > >> >> (There is some comment in the code about the height of the characters >> and the apparent mismatch about what was expected ... Maybe that is a >> clue?) > > I also think that this is the place to start. The fundamental issue here is that PLplot and the various fonts have a different origin for characters so a transformation has to be applied between the two depending on font size. The history here is that Andrew was the original author of plfreetype.c, and I assume he got this transformation done correctly for the windows fonts available to him at that time on his DJGPP (or was that MinGW?) platform. But that transformation was not correct for freefont 2003, and Rafael hacked the code to correct that. There was no feedback from Andrew about whether those hacks messed up the transformation for his windows fonts so I assumed until now that it was a solved problem. However, from Werner's report it appears not. Werner, I only know of this issue in overview, but if you find a correction to the plfreetype.c code that does the transformation automatically and correctly for all fonts using the font size information that I presume is included with each TrueType font, I would be very happy to accept your patch. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Werner S. <sm...@ia...> - 2006-01-05 12:03:44
|
Hi all, > transformation for his windows fonts so I assumed until now that it was a > solved problem. However, from Werner's report it appears not. Here ( http://eaps4.iap.tuwien.ac.at/~smekal/plplot_fonttest/ ) you can find the output of the png driver (which output is practically identical to the wxWidgets driver output) for 4 different fonts: x01_arial.png (windows fonts) x01_freefont2005.png x01_orig.png (from the plplot homepage freefont 2003) x01_vera.png (bitstream fonts) Some symbols are not shown, but I assume, the font just don't provide these symbols. Freefont 2005 is vertically misaligned, Bitstream is horizontally misaligned. All (except the original png) plots were done on Windows with the png driver. Regards, Werner |
From: Arjen M. <arj...@wl...> - 2006-01-09 07:53:54
|
Werner Smekal wrote: > > Hi all, > > > transformation for his windows fonts so I assumed until now that it was a > > solved problem. However, from Werner's report it appears not. > > Here ( http://eaps4.iap.tuwien.ac.at/~smekal/plplot_fonttest/ ) you can > find the output of the png driver (which output is practically identical > to the wxWidgets driver output) for 4 different fonts: > > x01_arial.png (windows fonts) > x01_freefont2005.png > x01_orig.png (from the plplot homepage freefont 2003) > x01_vera.png (bitstream fonts) > > Some symbols are not shown, but I assume, the font just don't provide > these symbols. Freefont 2005 is vertically misaligned, Bitstream is > horizontally misaligned. All (except the original png) plots were done > on Windows with the png driver. > Hello all, I have made considerable progress, but I am not there yet, unfortunately: 1. Andrew Roach had a suggestion to work around the nasty bug. That did work out: - I now have a nice initial display of the title and the axis labels as well as the symbols for example 1. This revealed by the way that the initial sizes of the window (the ones reported during the init function) are different than the eventual ones reported during the first WM_PAINT event. - If I resize the window, it is still a nice display as long as I keep the aspect ratio the same. It fails, however, if the window's aspect ratio changes: the Freetype interface allows me to set one scale factor but somehow I need both a horizontal and a vertical one. Is that specific to the win3 driver? Anyway, with another few tweaks it should work nicely. 2. I found most fonts to make example 24 work under Windows/win3 too: Example 24 using the win3 driver, properly displays the Chinese and Bengali (or Hindi) text. The only thing missing now is the Korean text. For your information: - I downloaded raghu.ttf: from: http://manaskriti.com/kaavyaalaya/installinghindi.html - I downloaded Cyberbit.ttf from: ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/ Now I need to consolidate the procedure and document this all. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-01-05 16:01:03
|
On 2006-01-05 13:03+0100 Werner Smekal wrote: > Hi all, > >> transformation for his windows fonts so I assumed until now that it was a >> solved problem. However, from Werner's report it appears not. > > Here ( http://eaps4.iap.tuwien.ac.at/~smekal/plplot_fonttest/ ) you can find > the output of the png driver (which output is practically identical to the > wxWidgets driver output) for 4 different fonts: > > x01_arial.png (windows fonts) > x01_freefont2005.png > x01_orig.png (from the plplot homepage freefont 2003) > x01_vera.png (bitstream fonts) > > Some symbols are not shown, but I assume, the font just don't provide these > symbols. Freefont 2005 is vertically misaligned, Bitstream is horizontally > misaligned. All (except the original png) plots were done on Windows with the > png driver. Thanks for that comparison, Werner. I have stared a long time at the bitstream result and can find absolutely nothing wrong with it except the size of the font is big relative to the others, but that is just a fact of life when comparing one font with another. Can you be specific about the horizontal misalignment that you see in that plot or were you thinking of some different example? I do agree there is something like a 25 per cent character height vertical shift for freefont 2005, but your other 3 examples seem fine and apparently so are all the other fonts that Andrew has looked at. Thus, aside from this one freefont 2005 case, it appears the current algorithm is doing well in keeping results aligned for the png device. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |