From: Arjen M. <arj...@wl...> - 2004-12-15 09:51:44
|
Rafael Laboissiere wrote: > > > > > Launch gucharmap > > > > view --> by unicode block > > > > lower left GUI box, choose mathematical operators > > > > upper left GUI box, move through fonts by up/down arrows to see what they > > all look like for the mathematical operators. > > > I used gfontview and inspect the font table for both FreeSans and Arial. > Try the following: > > Launch gfontview > > upper GUI box, select "/usr/share/fonts/truetype/freefont" > > file selection GUI, select "FreeSans" > I can not but envy you guys (well, I could go to a little corner in my office, sit down and sob a bit ;)) - neither command seems to exist on the Linux boxes I have access to right now. I will have to confront my sysadmins about this. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-12-15 17:57:06
|
On 2004-12-15 10:51+0100 Arjen Markus wrote: > I can not but envy you guys (well, I could go to a little corner > in my office, sit down and sob a bit ;)) :-) > - neither command seems > to exist on the Linux boxes I have access to right now. > > I will have to confront my sysadmins about this. Sometimes sysadmins like to keep their life simple by refusing to install anything but the most basic Linux apps. Another option if you have an older unused box at home or one of your friends is willing to give you such a box is to try installing a Linux distro on it to revive it. Then you are in command of your own destiny, and don't have to beg from your sysadmin. That is a wonderful feeling! It used to be extremely hard to install Linux, but now it is dead simple even with Debian (so long as you avoid some pitfalls by talking to experienced Debian users like Rafael, Andrew Ross, Andrew Roach, David Schleef, or me). I normally don't have much _recent_ Linux install experience because I usually go a couple of years between Linux installs (yes it really is that stable). But this year was different. I installed Debian testing (note I used the new Debian installer, not the default one) on one of my old computers, a new computer I bought, and an old computer and two new computers belonging to my Linux computer club. Each install was fast and easy. The three new computers were 2.4GHz/500MB class. The older two machines were 450MHz/256MB class (just a server for the club that runs no desktop at all) and a 600MHz/768MB class machine that is used extensively (and happily) by my wife as her personal KDE desktop. I use it as well sometimes and cannot really tell any difference in the desktop experience compared to my 2.4GHz/500MB machine which illustrates the point that good Linux desktop experience depends on size of memory more than cpu speed. Note, you could still probably get acceptable Linux results using the heavyweight GNOME or KDE desktops with even a 600MHz/128MB class machine. If you chose a lighter-weight desktop such as FVWM (also available for Debian testing along with lots of other light-weight desktop choices), you could run it easily (I have done so in the past) with good desktop response on a pentium-133 with 32MB! Of course that is an extreme case, and you can probably do a lot better than that in finding an unused machine. Anyhow, there are a lot of good PC's being thrown away now because they don't have the resources to run newer versions of windows, and those "throwaway" machines are an excellent choice for developing your Linux skills. 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...> - 2004-12-16 09:31:58
|
"Alan W. Irwin" wrote: > > On 2004-12-15 10:51+0100 Arjen Markus wrote: > > I can not but envy you guys (well, I could go to a little corner > > in my office, sit down and sob a bit ;)) > > :-) > > > - neither command seems > > to exist on the Linux boxes I have access to right now. > > > > I will have to confront my sysadmins about this. > > Sometimes sysadmins like to keep their life simple by refusing to install > anything but the most basic Linux apps. > > Another option if you have an older unused box at home or one of your > friends is willing to give you such a box is to try installing a Linux > distro on it to revive it. Then you are in command of your own destiny, and > don't have to beg from your sysadmin. That is a wonderful feeling! > Well, I have Linux at home, but the box is a bit slow to really do work on it... or is that my Internet connection? Anyhow, I need to get more acquainted with things Linuxy than I am now :) Without further ado: 1. I have incorporated the patch by Bryan Peterson regarding the Enter key into win3.cpp. This is a new branch in the event handler (rather than the quick hack he added to plD_eop_win3(). This works as expected, so this ought to be much cleaner. 2. I have experimented with the PNG driver. This works quite nicely! It requires a few changes to various files and the user must get the bgd.dll library and stuff, put several files in the right place, but then it works. I want to use the configuration tool I proposed to make the necessary changes automatically. Then a few installation notes and everybody will be able to get PNG, JPEG etc on Windows too. 3. I also experimented with freetype fonts. The problem there is, however, that the bgd.dll library comes with freetype fonts included, but not with the necessary header files. As I do not yet know how this feature is accessed, I loathe to make random additions to the make directory. I will have to look into this problem ;) 4. The configuration tool (in its infancy) now does some manipulation for single/double precision - an issue for the Fortran examples. Not yet in CVS, but this will allow us to maintain a single set (and either use this tool or sed when available to make the changes). 5. The next step is to get _all_ the drivers into the Windows version - as long as they make sense on that platform. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2004-12-17 20:03:36
|
This has been a long thread already, but I want to share some additional font knowledge I discovered yesterday having to do with the postscript type 1 fonts on Linux. This knowledge ultimately confirms that the offset to access mathematical symbols such as nabla (U+2207 or Hershey code, #(2266)) with the postscript fonts is the same as other Linux-installed fonts, and indeed the mathematical symbol coverage by postscript fonts is adequate. (I always check nabla since nabla subscript a is an often-used symbol in equation-of-state research for one of the thermodynamic gradients.) The gv postscript viewing application depends on gs-gpl which in turn recommends gsfonts. That latter package holds the gs related fonts under Linux. To figure out what the associated font family names are for the 35 fonts in gsfonts, do the following command: grep -h FamilyName /usr/share/fonts/type1/gsfonts/*.afm |sort |uniq The results are the following: FamilyName Century Schoolbook L FamilyName Dingbats FamilyName Nimbus Mono L FamilyName Nimbus Roman No9 L FamilyName Nimbus Sans L FamilyName Standard Symbols L FamilyName URW Bookman L FamilyName URW Chancery L FamilyName URW Gothic L FamilyName URW Palladio L To make these font families accessible for X display (and therefore for gucharmap), install the gsfonts-x11 package. Then under gucharmap choose the "Standard Symbols L" font family and check out nabla and other mathemetical symbols from the Hershey fonts for completeness using the right-click trick. Here is a summary table of what is available in "Standards Symbols L" for certain math symbols in the Hershey fonts. (Andrew Roach has privately told me he has already assembled a Hershey to unicode translation for all Hershey codes, but I did this independently here using gucharmap so he will have an independent check of his work for this critical region of Hershey codes. This table also gives us a feeling for what is present for "Standards Symbols L" for this region of Hershey code. After struggling with putting this table together, I now have a much greater appreciation of the large amount of work Andrew must have already put into his Hershey to unicode index translation table.) Hershey Unicode Present code 2233 U+00B1 PLUS-MINUS SIGN x 2234 U+2213 MINUS-OR-PLUS SIGN 2235 U+00D7 MULTIPLICATION SIGN x 2236 U+22C5 DOT OPERATOR x 2237 U+00F7 DIVISION SIGN x 2238 U+003D EQUALS SIGN x 2239 U+2260 NOT EQUAL TO x 2240 U+2261 IDENTICAL TO x 2241 U+003C LESS-THAN SIGN x 2242 U+003E GREATER-THAN SIGN x 2243 U+2266 LESS-THAN OVER EQUAL TO 2244 U+2267 GREATER-THAN OVER EQUAL TO 2245 U+221D PROPORTIONAL TO x 2246 U+223C TILDE OPERATOR x 2247 U+2038 CARET x 2255 U+2713 CHECK MARK 2265 U+2202 PARTIAL DIFFERENTIAL x 2266 U+2207 NABLA x 2267 U+2714 HEAVY CHECK MARK 2268 U+222B INTEGRAL x 2269 U+222E CONTOUR INTEGRAL 2270 U+221E INFINITY x So "Standard Symbols L" is missing some Hershey symbols and is definitely much less complete than the free fonts (which include all these symbols and much more, see, for example, the various kinds of integral signs that are represented). Nevertheless, from the above table the "Standard Symbols L" type 1 font family includes quite a few useful math symbols. Thus, I think the proposed hershey to unicode translation in the PLplot core code will be an excellent help for expressing mathematical symbols both in the plfreetype case (where the free fonts have terrific coverage of mathematical symbols) and the postscript driver case (where the postscript fonts seem to have adequate coverage of mathematical symbols via the "Standard Symbols L" family of fonts in gsfonts). I have also spot checked the "Standard Symbols L" family for Greek symbols, and most seem to be there according to gucharmap in the standard positions. Exceptions I found (and this may not be the complete list) are the Capital delta and mu glyphs which are missing in their standard positions, U+0394 GREEK CAPITAL LETTER DELTA and U+03BC GREEK SMALL LETTER MU. One can substitute U+2206 INCREMENT and U+00B5 MICRO SIGN which are present for the "Standard Symbols L" family, but at best this seems to be quite a peculiarity in ordering for the gsfonts. I don't know if I am missing something here or the gsfonts team just dropped the ball on those two Greek letters. Rafael has already made the point encouraging centralized Hershey to unicode translation for the Greek symbols in PLplot for use in both plfreetype.c and ps.c, but my experiments today with what is available from gsfonts indicate the same point can be made for most of the mathematical symbols above. Of course our Debian users could try gsfonts-other which specifically includes Hershey fonts, but when I looked at those with gucharmap there didn't seem to be any support of Greek characters or math symbols (and of course before Rafael points it out, I should mention that gsfonts-other is non-free according to Debian). I assumed for the work reported above that it is not possible to make the FreeMono, FreeSans, and FreeSerif TrueType font families to display nicely with postscript files so that is why I have been concentrating on the free type1 font families (especially "Standard Symbols L") available from gsfonts and gsfonts-x11. However, apparently there is at least some truetype support built into gs according to http://howtos.linux.com/howtos/TT-Debian-4.shtml . Has anybody got gs to work with FreeMono et al.? If gs support of truetype gives good-looking results, then perhaps there is a way for us to specify use of truetype fonts from ps.c. That would give us the _potential_ (once the #g and numerical access methods are sorted out and we are ready to move forward on the more difficult problem of accessing unicode fonts from PLplot using UTF-8 strings) to access the rather complete coverage of mathematical symbols, Greek characters, and non-Latin and non-Greek characters that are in the free truetype fonts. 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: Rafael L. <rla...@us...> - 2004-12-17 22:07:37
|
* Alan W. Irwin <ir...@be...> [2004-12-17 12:02]: > This has been a long thread already, but I want to share some additional > font knowledge I discovered yesterday having to do with the postscript type > 1 fonts on Linux. [...] Thanks for this thorough report on your experiments about using TT fonts in Postcript. Just a comment for now: > I assumed for the work reported above that it is not possible to make the > FreeMono, FreeSans, and FreeSerif TrueType font families to display nicely > with postscript files so that is why I have been concentrating on the free > type1 font families (especially "Standard Symbols L") available from gsfonts > and gsfonts-x11. I am not sure that there is currently a way to use TrueType fonts directly as Postscript fonts in a portable way. The big problem is that PostScript fonts are limited to 256 characters. On the other hand, instead of following the type 1 road you are proposing, I planned to borrow code from World Print (a.k.a. wprint, see (http://www.esperanto.org.uy/programoj/angle/) for the ps driver. wprint does a very smart thing: using the libfreetype library, it opens an arbitrary *.ttf file and get the Bezier path for each needed character. After that, it generates the Postscript code for drawing the characters and packs it into a PS font that is included in the preamble of the PS file. This is guaranteed 100% portable across any printer. I played with the examples in the wprint package in my Debian testing system to produce PS output for mathematical symbols with FreeFont. Look at this preliminary hack: http://people.debian.org/~rafael/test-wprint.ps The file above is fully portable and should be rendered exactly in the same way in any OS/viewer/printer (think of dvips files, which are also 100% portable). This is a clear demonstration that FreeSans can in fact be nicely/portably displayed with PS files. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-12-18 18:07:43
|
On 2004-12-17 23:07+0100 Rafael Laboissiere wrote: > > I am not sure that there is currently a way to use TrueType fonts directly > as Postscript fonts in a portable way. The big problem is that PostScript > fonts are limited to 256 characters. > > On the other hand, instead of following the type 1 road you are proposing, I > planned to borrow code from World Print (a.k.a. wprint, see > (http://www.esperanto.org.uy/programoj/angle/) for the ps driver. wprint > does a very smart thing: using the libfreetype library, it opens an > arbitrary *.ttf file and get the Bezier path for each needed character. > After that, it generates the Postscript code for drawing the characters and > packs it into a PS font that is included in the preamble of the PS file. > This is guaranteed 100% portable across any printer. Just out of curiosity, what happens if you have more than 256 different characters in your plot annotations? Is there room in the font stored in the preamble? (Unlikely, scenario, I agree, but I was just wondering if that is one practical result of the 256 limit you state above?) What you describe above sounds like on-the-fly conversion from true-type format for the glyphs to a format (type 1?) for the same glyphs that postscript understands, and putting the result in the postscript preamble for maximum portability. If that is a fair summary, the idea sounds good to me and also appeals because FreeSans, for example, is much more complete than gsfonts. Others could object this approach might be cpu intensive and substantially slow down generation of postscript plots in the case when TT fonts are used. But I don't think that is a particularly important issue; if it turns out to be a noticeable problem (and I am not sure that would be the case), you could do most of your plot script development with quick Hershey or Type 1 fonts, and just do the final polish of your postscript plot with the slower but more complete TT fonts. Of course, the wprint approach does not preclude using type 1 fonts from gsfonts as well since apparently all you have to do is have central infrastructure in place to transmit the right 4-byte unicode index from core to ps.c or plfreetype.c, and in ps.c you will be able to index the existing type 1 gsfont with virtually no extra ps.c programming required. In sum, I say go for both; type 1 support for ps.c is easy, and when time permits you can add in code borrowed from wprint to support TT fonts with the borrowed wprint code. I am not wedded to type 1, of course. So we can always drop it from ps.c if the wprint approach turns out in practice to be overwhelmingly better, but I believe we should keep the type 1 support for now because it costs so little effort to implement. > > I played with the examples in the wprint package in my Debian testing > system to produce PS output for mathematical symbols with FreeFont. Look at > this preliminary hack: > > http://people.debian.org/~rafael/test-wprint.ps > > The file above is fully portable and should be rendered exactly in the same > way in any OS/viewer/printer (think of dvips files, which are also 100% > portable). This is a clear demonstration that FreeSans can in fact be > nicely/portably displayed with PS files. Nice proof of concept! The more we see images like this which illustrate the possibilities, the more enthusiastic I think all of us are getting about helping out with the on-going font revolution for PLplot. So Andrew (Roach), let the other developers know if you need any help getting the ball rolling on the programming of the centralized infrastructure for core translation of Hershey indices to unicode indices following the design that Rafael proposed (just sticking with #g and #(nnnn) access methods for now). Or if you don't have time over Christmas to do the programming, you might want to make your Hershey to unicode data file available for download so some other developer can take a first crack at the necessary programming. 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: Rafael L. <rla...@us...> - 2004-12-18 19:15:06
|
* Alan W. Irwin <ir...@be...> [2004-12-18 10:07]: > Just out of curiosity, what happens if you have more than 256 different > characters in your plot annotations? Is there room in the font stored in > the preamble? (Unlikely, scenario, I agree, but I was just wondering if that > is one practical result of the 256 limit you state above?) In the case the 256 limit is exceeded (which is unlikely to happen), just create a second font in the preamble. > What you describe above sounds like on-the-fly conversion from true-type > format for the glyphs to a format (type 1?) for the same glyphs that > postscript understands, [...] Not really. > [...] and putting the result in the postscript preamble for maximum > portability. This part is true. > If that is a fair summary, [...] No, it is not. What wprint does is to use the PS command "definefont" to create the font. Each glyph is defined using the PS commands "moveto", "lineto" and "curveto" commands. We cannot really call this a conversion to another font format, it is rather pure PostScript code usage. For instance, in the file test-wprint.ps I put in my web page, this is how the Nabla character is defined: /S { % U2207 711 0 10 0 701 729 setcachedevice 10 729 moveto 304 0 lineto 404 0 lineto 701 729 lineto closepath 355 113 moveto 143 647 lineto 566 647 lineto closepath fill } bind def (The Nabla character happens to occupy the place of letter "S" in the generated t1 font.) > [...] the idea sounds good to me and also appeals because FreeSans, for > example, is much more complete than gsfonts. Others could object this > approach might be cpu intensive and substantially slow down generation of > postscript plots in the case when TT fonts are used. But I don't think that > is a particularly important issue; [...] I am almost sure that this will be an issue. However, the generated PS files will be significantly bigger. > Of course, the wprint approach does not preclude using type 1 fonts from > gsfonts as well since apparently all you have to do is have central > infrastructure in place to transmit the right 4-byte unicode index from core > to ps.c or plfreetype.c, [...] Put gnome.c and plplotcanvas as potential candidates for this list. > So Andrew (Roach), let the other developers know if you need any help > getting the ball rolling on the programming of the centralized > infrastructure for core translation of Hershey indices to unicode indices > following the design that Rafael proposed (just sticking with #g and #(nnnn) > access methods for now). Or if you don't have time over Christmas to do the > programming, you might want to make your Hershey to unicode data file > available for download so some other developer can take a first crack at the > necessary programming. Yes, please. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-12-18 20:52:57
|
On 2004-12-18 20:15+0100 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-12-18 10:07]: >> What you describe above sounds like on-the-fly conversion from true-type >> format for the glyphs to a format (type 1?) for the same glyphs that >> postscript understands, [...] > > Not really. > >> [...] and putting the result in the postscript preamble for maximum >> portability. > > This part is true. > >> If that is a fair summary, [...] > > No, it is not. What wprint does is to use the PS command "definefont" to > create the font. Each glyph is defined using the PS commands "moveto", > "lineto" and "curveto" commands. We cannot really call this a conversion to > another font format, it is rather pure PostScript code usage. For instance, > in the file test-wprint.ps I put in my web page, this is how the Nabla > character is defined: > > /S { % U2207 > 711 0 10 0 701 729 setcachedevice > 10 729 moveto > 304 0 lineto > 404 0 lineto > 701 729 lineto > closepath 355 113 moveto > 143 647 lineto > 566 647 lineto > closepath fill } bind def Thanks for these details of the format you had in mind. However, you shouldn't be so sensitive about the language of my summary when there really is no controversy at all. Perhaps you misunderstood "(type 1?)" in the summary or didn't see that question mark? That question mark means this is one of many possibilities for the format, and therefore the summary is quite general. Of course, now that you have been more specific about the format, you can make the summary more specific as well by replacing the indefinite "(type 1?)" by the specific "(pure postscript code)". But proceeding from the general to the specific is always a good idea as more information becomes available, and there is nothing here to argue about. 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: Rafael L. <rla...@us...> - 2004-12-19 15:23:14
|
* Alan W. Irwin <ir...@be...> [2004-12-18 12:52]: > Thanks for these details of the format you had in mind. However, you > shouldn't be so sensitive about the language of my summary when there > really is no controversy at all. You are right, there was no controversy there. I was just trying to be more precise and to avoid sources of misunderstandings in the future. -- Rafael |
From: Andrew R. <aro...@ya...> - 2004-12-19 03:20:25
|
I think the old topic "Re: [Plplot-devel] Freetype "bug" in Debian packages" is starting to get a bit stale, so I have changed it. At 10:07 AM 18/12/2004 -0800, Alan W. Irwin wrote: >So Andrew (Roach), let the other developers know if you need any help >getting the ball rolling on the programming of the centralized >infrastructure for core translation of Hershey indices to unicode indices >following the design that Rafael proposed (just sticking with #g and #(nnnn) >access methods for now). Or if you don't have time over Christmas to do the >programming, you might want to make your Hershey to unicode data file >available for download so some other developer can take a first crack at the >necessary programming. I should, from this week, *finally* have some time to do some work on this. I have a "conceptional model" as to how I am going to go about it, and the raw table for conversion is, I think as advanced as I can make it with my eyes (although, as I have said before, many glyphs just look like squiggles to me !). I made the table by using a unicode browser program and a printed out copy of the Hershef font tables, and looked for matches. There are 949 Hershey fonts by my count, and 760 of them I have been able to match up to a unicode glyph. I know that might sound like a lot are missing, but I think most of the important ones have been matched, and it is mainly the more abstract ones left over. The process is not infallible, so I am sure that many of those blanks could be filled up with another set of eyes, and I probably also have some "wrong" (one has to make some arbitary assumptions here and there). I made the table using OpenOffice's spreadsheet program, and if anyone wants to have a go at adding the missing glphs they are welcome to have the table, just let me know what format works best for you. Eventually I am going to have a plain ASCII three field table (hershey, unicode, hershey font face number), but while it is still being edited it is a little easier to maintain as a spreadsheet. Alternately, if anyone wants a list of the missing glpys only, I'd could send that across, or even post it here to the developers list. -Andrew |
From: Alan W. I. <ir...@be...> - 2004-12-19 06:53:48
|
On 2004-12-19 13:20+1000 Andrew Roach wrote: > I think the old topic "Re: [Plplot-devel] Freetype "bug" in Debian packages" > is starting to get a bit stale, so I have changed it. > > At 10:07 AM 18/12/2004 -0800, Alan W. Irwin wrote: >> So Andrew (Roach), let the other developers know if you need any help >> getting the ball rolling on the programming of the centralized >> infrastructure for core translation of Hershey indices to unicode indices >> following the design that Rafael proposed (just sticking with #g and >> #(nnnn) >> access methods for now). Or if you don't have time over Christmas to do >> the >> programming, you might want to make your Hershey to unicode data file >> available for download so some other developer can take a first crack at >> the >> necessary programming. > > I should, from this week, *finally* have some time to do some work on this. I > have a "conceptional model" as to how I am going to go about it, and the raw > table for conversion is, I think as advanced as I can make it with my eyes > (although, as I have said before, many glyphs just look like squiggles to me > !). I made the table by using a unicode browser program and a printed out > copy of the Hershef font tables, and looked for matches. There are 949 > Hershey fonts by my count, and 760 of them I have been able to match up to a > unicode glyph. I know that might sound like a lot are missing, but I think > most of the important ones have been matched, and it is mainly the more > abstract ones left over. The process is not infallible, so I am sure that > many of those blanks could be filled up with another set of eyes, and I > probably also have some "wrong" (one has to make some arbitary assumptions > here and there). I made the table using OpenOffice's spreadsheet program, and > if anyone wants to have a go at adding the missing glphs they are welcome to > have the table, just let me know what format works best for you. Eventually I > am going to have a plain ASCII three field table (hershey, unicode, hershey > font face number), but while it is still being edited it is a little easier > to maintain as a spreadsheet. Alternately, if anyone wants a list of the > missing glpys only, I'd could send that across, or even post it here to the > developers list. My advice is not to worry about refining these index transformation data for now. Instead, I suggest you simply plunge ahead with the minimal part of programming that gets just #(nnnn) access to work with your current data as we have already discussed, check in the results, and then the rest of us can join in and help you. For example, as soon as that #(nnnn) programming is done, I can also reprogramme plsym to call plmtex with the appropriate #(nnnn) code. This simple change will make all of the example 7 results be responsive to font changes, not just the outer number display as now. Thus, simply running example 7 alternatively with Hershey font and FreeSans font for -dev png should give a good comparison between the two fonts for everything available from Hershey and quickly turn up any remaining index transformation data difficulties. Furthermore, since your index transformation data will be part of a PLplot source code and therefore under cvs control, that gives automatic and extremely useful coordination of updates of those data for our developers who do sit down to compare Hershey and non-Hershey results for example 7. In sum, everybody now deeply interested in the PLplot font revolution can easily help out in a variety of ways as soon as #(nnnn) access minimally works for true-type fonts. 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...> - 2004-12-14 01:49:54
|
At 09:26 AM 13/12/2004 -0800, you wrote: >According to gucharmap both the free and MS fonts (including Arial.ttf) have >all the math symbols starting at U+2200 as I have stated before. Here is >exactly what you should do to confirm that on your system. >[snip] >Rafael, since the presence or absence of the math symbols in each font is an >important point, and the gucharmap results directly contradict what you >stated above, could you please compare gucharmap results with whatever font >comparison application gave you the contradictory information above to >figure out what is going on? Something which might be worth mentioning is there may be many different versions of the same font out there. For windows users, the stock-standard windows fonts come in different versions depending on which country the version of windows is licensed too, and which version of windows you have. Maybe the boys in Redmond are xenophobic or something, but the Arial and Times fonts which ship to non-English Europe have thousands of extra glyphs in them the US/UK/Australian versions don't have. There are also Arial and Times fonts tucked away on the MS web site that had TENS OF THOUSANDS of glyphs, and are supposed to be around the most complete packs out there. They are breath takingly large in their girth (something like 80 meg+ downloads), so I have never looked at then, and I guess I can understand why, at that size, they don't ship as standard ! -Andrew |
From: Arjen M. <arj...@wl...> - 2004-12-15 09:55:52
|
Andrew Roach wrote: > > Something which might be worth mentioning is there may be many different > versions of the same font out there. For windows users, the stock-standard > windows fonts come in different versions depending on which country the > version of windows is licensed too, and which version of windows you have. > Maybe the boys in Redmond are xenophobic or something, but the Arial and > Times fonts which ship to non-English Europe have thousands of extra glyphs > in them the US/UK/Australian versions don't have. There are also Arial and > Times fonts tucked away on the MS web site that had TENS OF THOUSANDS of > glyphs, and are supposed to be around the most complete packs out there. > They are breath takingly large in their girth (something like 80 meg+ > downloads), so I have never looked at then, and I guess I can understand > why, at that size, they don't ship as standard ! > I don't understand it - their system is huge as it is, a mere 80 MB extra should not make much difference :) I remember the days that a compiler fitted on a single floppy disk, okay, DSDD, I admit. Or a word processor, without the dictionary .... Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2004-12-15 10:02:53
|
"Alan W. Irwin" wrote: > > > For the others here, I jumped directly from Unix to Linux with no stopovers > in the windows world. I cannot claim any great virtue because of this. > Instead, I was just lucky that Linux fit my scientific computing needs so > well even back in 1996 and of course ever since. Perhaps because of my zero > experience with windows, I am more tolerant of windows and Bill Gates then > Rafael seems to be. Anyhow, I am happy to encourage Arjen to make PLplot > work well on windows including good font access, and I think Rafael has the > same attitude. > Thank you for these supportive words. I have avoided the font questions so far, because they are complex and rather arcane. MS Windows does come with a lot of them and I mostly use them via word processors. For the users of my program(s) the inconvenient (hidden) access to "special" symbols (how special can they be, if whole nations and peoples use them on a daily basis?) has caused them not to raise too many questions. But I would dearly like to see this support made clearer. As a matter of fact: I have set the first steps in getting the gd library into the Windows version - this seems to be fairly simple and the prebuilt library available from the gd home page comes with freetype included. Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-12-10 22:05:18
|
* Alan W. Irwin <ir...@be...> [2004-12-10 10:22]: > On 2004-12-10 18:22+0100 Rafael Laboissiere wrote: > > >* Alan W. Irwin <ir...@be...> [2004-12-10 09:05]: > > > >>I plan to remedy that if you feel the free fonts are even in the same > >>class > >>with the MS ones based on your honest comparisons using PLplot examples. > >>If > >>you can confirm they are in the same class, what is the recipe for using > >>the free replacement fonts on Debian testing? I will need package name, > >>directory, and font names. > > > >$ apt-cache search --names-only ^ttf- > >$ dpkg -L ttf-freefont | fgrep .ttf > > That's a partial answer to my question which avoids the important part. You > previously asserted that the free solution was as good as the MS one. Can > you honestly confirm that from your own experience? Appearance matters > big-time for scientific publications so I don't want to compromise that. Thanks to the recent changes in configure made by Andrew Ross (thanks a lot Andrew!), I generated a PNG file for the x12c example using FreeFont. Look at the result at: http://people.debian.org/~rafael/x12c.png and judge by yourself. -- Rafael |
From: Rafael L. <rla...@us...> - 2004-12-10 17:38:36
|
* Alan W. Irwin <ir...@be...> [2004-12-10 09:05]: > How good? I read the Linux literature pretty closely, and everything I have > read up to now says the MS fonts are some of the best freely available > fonts, and certainly they are excellent as confirmed by some of my recent > research plots that have used them. The MS fonts can be freely used ("free" as in "gratis"), but cannot be freely distributed ("free" as in "freedom"). This is the reason the msttcorefonts package is not in Debian main. In sum, the MS fonts are non-free software. Period. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-12-11 00:36:03
|
On 2004-12-10 23:05+0100 Rafael Laboissiere wrote: > Thanks to the recent changes in configure made by Andrew Ross (thanks a lot > Andrew!) Thanks from me as well, Andrew! > I generated a PNG file for the x12c example using FreeFont. Look > at the result at: > > http://people.debian.org/~rafael/x12c.png > > and judge by yourself. Thanks Rafael for that example. A picture is worth 10000 words! That example looks really nice, and is a most convincing argument for free fonts especially if there is a decent free option for mathematical symbols and Greek letters. How can I reproduce that example myself? I don't want to wade through a zillion possibilities for free font packages, and font names within those packages. So I would appreciate it if you were quite specific about what font package(s) you are using, and exactly what configure options. In particular what free font do you recommend for the symbols and Greek letters? Once I have the specifics from you, I will try example 3 which does have one Greek symbol, and if that looks good, I will try some more examples including my research plots. If everything is satisfactory with those examples with your recommended ./configure font options, then that answers all my questions, and I would be more than happy to adopt those free font ./configure options as default on the Linux/Unix side. One additional issue is our examples on the web site. It is almost shocking to compare http://plplot.sourceforge.net/examples-data/demo12/x12.01.png with the nice result above. There is no question which we would all prefer as an advertisement for PLplot. Fonts are clearly a headache to deal with, but well worth it since it will bring a great new look to PLplot results that was just not available before with the Hershey fonts. 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: Alan W. I. <ir...@be...> - 2004-12-09 22:06:19
|
On 2004-12-09 20:35-0000 Andrew Ross wrote: > > On Debian plplot is linked with the freetype library. By default this > assumes the Microsoft core truetype fonts are available (at least Arial, > Times New Roman, Times New Roman Italic, and Comic Sans MS. These are > installed by the msttcorefonts package which the Debian plplot packages > should probably at least recommend. Even if this package is installed > the fonts are put in /usr/share/fonts/truetype/msttcorefonts/ not in the > location /usr/share/fonts/truetype/ which plplot assumes. Perhaps for > the Debian packages we should patch the source to change the default. > > Otherwise we should make sure the environment variable > PLPLOT_FREETYPE_FONT_PATH is well documented so users can set the path > themselves. I only found out about this by reading the source! > > What do other distributions do? Should we change the default for all > users? Patching just the Debian source will not be necessary since I just made the change in PLplot upstream (see below). The original bad default location is my fault. I just took whatever happened to be on my old Debian stable system (probably the result of a download rather than a specific package install). That old system has now been replaced with Debian testing which (as you state) has the /usr/share/fonts/truetype/msttcorefonts/ install location for the MS fonts. Also, I have looked at the msttcorefonts-1.3-4.spec spec file at the upstream source web site (http://sourceforge.net/project/showfiles.php?group_id=34153), and the default install location there is also now /usr/share/fonts/truetype/msttcorefonts/. Thus, so long as the various rpm builders don't fiddle with this, then we should have a uniform install location for both debs and rpms of /usr/share/fonts/truetype/msttcorefonts/. As a result of this research I think it is a no-brainer to change the default location to be /usr/share/fonts/truetype/msttcorefonts/ so I have just committed that change which takes care of one issue. However, in agreement with Andrew, I believe Rafael should think about the appropriate "recommends" for his Debian package, and the environment variables associated with plplotfreetype should be documented for those who want to try non-default fonts or fonts that have been installed in a non-default location. 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. <and...@us...> - 2004-12-09 23:44:09
|
On Thu, Dec 09, 2004 at 02:05:58PM -0800, Alan Irwin wrote: > On 2004-12-09 20:35-0000 Andrew Ross wrote: > > As a result of this research I think it is a no-brainer to change the > default location to be /usr/share/fonts/truetype/msttcorefonts/ so I have > just committed that change which takes care of one issue. However, in > agreement with Andrew, I believe Rafael should think about the appropriate > "recommends" for his Debian package, and the environment variables > associated with plplotfreetype should be documented for those who want to > try non-default fonts or fonts that have been installed in a non-default > location. Actually, thinking about it I agree with Raphael that we might be better of making the free fonts the default, or at least search for them as well. We probably want to leave the MS ones for windows users. Andrew |
From: Arjen M. <arj...@wl...> - 2004-12-10 08:31:02
|
Andrew Ross wrote: > > On Thu, Dec 09, 2004 at 02:05:58PM -0800, Alan Irwin wrote: > > On 2004-12-09 20:35-0000 Andrew Ross wrote: > > > > As a result of this research I think it is a no-brainer to change the > > default location to be /usr/share/fonts/truetype/msttcorefonts/ so I have > > just committed that change which takes care of one issue. However, in > > agreement with Andrew, I believe Rafael should think about the appropriate > > "recommends" for his Debian package, and the environment variables > > associated with plplotfreetype should be documented for those who want to > > try non-default fonts or fonts that have been installed in a non-default > > location. > > Actually, thinking about it I agree with Raphael that we might be better > of making the free fonts the default, or at least search for them as > well. We probably want to leave the MS ones for windows users. > I have some trouble following this discussion (fonts are a cauldron of problems that I usually shy away from). Can you point out to me which examples might exhibit font problems, so that I can see what happens on Windows? Regards, Arjen |
From: Rafael L. <rla...@us...> - 2004-12-10 08:44:31
|
* Alan W. Irwin <ir...@be...> [2004-12-09 14:05]: > Patching just the Debian source will not be necessary since I just made the > change in PLplot upstream (see below). > > [...] > > As a result of this research I think it is a no-brainer to change the > default location to be /usr/share/fonts/truetype/msttcorefonts/ so I have > just committed that change which takes care of one issue. However, in > agreement with Andrew, I believe Rafael should think about the appropriate > "recommends" for his Debian package, and the environment variables > associated with plplotfreetype should be documented for those who want to > try non-default fonts or fonts that have been installed in a non-default > location. As I wrote in my previous post, I really, really, really dislike this solution, because it makes PLplot depend on non-free software. However, I respect your changes (after all, I am not the owner of the project) and will keep the m$ttcorefonts as the default, if/when I will eventually implement the configure options for choosing other fonts. At any rate, I will get rid of the m$ttcorefonts dependency/suggestion/recommendation in the next release of the Debian packages. Sorry for looking so radical, but I have a serious commitment with the Free Software movement. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-12-10 18:06:11
|
On 2004-12-10 09:44+0100 Rafael Laboissiere wrote: > Sorry for looking so radical, but I have a serious commitment with the Free > Software movement. I don't mind a bit. I am similarly radical. It's just that we must deal with things in the computer world every day that are not completely free such as all the hardware on most computers. So there are practical limits to how consistently radicial we can be about true computer freedom, and it is a matter of where you draw the boundaries. For me, certain aspects of PC hardware should be free. For example, I look forward to the day when the Linuxbios project becomes easy to use for all PC BIOS's as a replacement for buggy proprietary BIOS versions that make life awfully difficult (and slow) when Linux is attempting to boot. However, that day is not here yet (AFAIK) so I "hold my nose" and continue to use the proprietary BIOS. For me, all software should be completely free. I have zero experience with MS software, but I have had lots of experience with proprietary Unix , and Linux is just a lot better for my needs, and I am sure that was because there was freedom to improve it by a lot of programmers who had similar needs to mine. Similarly, I prefer to use truly free Java rather than the non-free versions from Sun, Blackwood, and IBM, and I was really pleased on the day that Andrew (Ross) showed me that free Java was practical for PLplot since that allowed me to remove my last dependence on non-free software. For me, computer art forms such as fonts are not software, but they should be completely free as well so that the result would be easy to modify and improve. Nevertheless, it is a similar situation to the hardware BIOS; since I want my research papers to look good, I don't want to switch until the free alternative gives as good (actually almost as good would do) a result as the non-free version. Like the BIOS situation, I am looking forward to making the switch to completely free fonts when the time comes. Perhaps that time is now? (See my last post.) 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 __________________________ |