Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2004-05-16 17:15:21
|
For the -dev png plots I am preparing for publication, I have been
attempting to use the TrueType fonts that are available with the png device
and the -drvopt text,smooth option. Normal characters that are on the line,
superscripted, or subscripted in either 2D and 3D plots seems to work. The
only trouble I am having is with special symbols and Greek letters.
Andrew (Roach), how do you specify the gradient sign with TrueType fonts?
With Hershey fonts I use #(2266) (as indicated with the correspondence
between numbers and symbols in example 7). I have the same question for
capital Greek Delta (which for Hershey fonts is specified with #gD). When I
try #gD with TrueType fonts, it just seems to make a short vertical mark,
and there is also the following error message
*** PLPLOT ERROR *** plscol0: Invalid RGB color: 252, 250, 256, aborting
operation
*** PLPLOT ERROR ***
plscol0: Invalid RGB color: 256, 252, 252, aborting operation
A related question is how do you find out what the correspondence is between
the #(nnnn) notation and particular symbols? Examples 6 and 7 are supposed
to do that, but it appears with -dev png -drvopt text,smooth option that
only the outer labels for the tables are printed with TrueType, but the
symbols within the tables are still done with the Hershey fonts. Andrew, can
you fix this?
System Details:
Debian stable. CVS version of PLplot. Currently I am using the default
TrueType fonts, which if you look at the plfreetype.c code are
static char *default_font_names[]={"Arial.ttf","Times_New_Roman.ttf",
"Times_New_Roman_Italic.ttf","Comic_Sans_MS.ttf","Arial.ttf"};
Here are the TrueType fonts (these are the downloadable core MS fonts)
available on my system:
ls /usr/share/fonts/truetype/
Andale_Mono.ttf Impact.ttf
Arial.ttf Times_New_Roman.ttf
Arial_Black.ttf Times_New_Roman_Bold.ttf
Arial_Bold.ttf Times_New_Roman_Bold_Italic.ttf
Arial_Bold_Italic.ttf Times_New_Roman_Italic.ttf
Arial_Italic.ttf Trebuchet_MS.ttf
Comic_Sans_MS.ttf Trebuchet_MS_Bold.ttf
Comic_Sans_MS_Bold.ttf Trebuchet_MS_Bold_Italic.ttf
Courier_New.ttf Trebuchet_MS_Italic.ttf
Courier_New_Bold.ttf Verdana.ttf
Courier_New_Bold_Italic.ttf Verdana_Bold.ttf
Courier_New_Italic.ttf Verdana_Bold_Italic.ttf
Georgia.ttf Verdana_Italic.ttf
Georgia_Bold.ttf Webdings.ttf
Georgia_Bold_Italic.ttf ms-fonts
Georgia_Italic.ttf
I can change the environment variables, PLPLOT_NORMAL_FONT,
PLPLOT_ROMAN_FONT, PLPLOT_ITALIC_FONT, PLPLOT_SCRIPT_FONT, and
PLPLOT_SYMBOL_FONT to point to any of these, but in order to properly
explore the font options, the tabulated symbols in examples 6 and 7 have to
be generated with TrueType fonts when those are specified by the user using
the -dev png -drvopt text,smooth options.
Andrew, if the modifications to examples 6 and 7 will take some discussion
and time, and meanwhile you know the specific answer to how to specify the
gradient symbol and Greek letters, please let me know since the gradient
symbol and Greek letters will take care of my immediate publication needs
for a while.
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 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-05-18 01:35:40
|
On 2004-05-16 10:14-0700 Alan W. Irwin wrote: > For the -dev png plots I am preparing for publication, I have been > attempting to use the TrueType fonts that are available with the png device > and the -drvopt text,smooth option. Normal characters that are on the line, > superscripted, or subscripted in either 2D and 3D plots seems to work. The > only trouble I am having is with special symbols and Greek letters. With private help from Andrew (Roach) I think my current publication needs are taken care of with some clumsy, but effective workarounds. On the dark side, there seems to be a current limitation that only the first 156 characters of any freetype font are accessible. My own feeling is that is unlikely to be a libfreetype issue since that library is heavily used by a lot of users. But Andrew is having trouble finding any place in the PLplot code where that limit is imposed. Off-hand does anybody know a place in our code where decimal 100 is added to the font index then effectively subtracted later? That would overflow an unsigned character and cause the symptoms we are seeing. On the bright side, I have been discovering a whole bunch of font options PLplot -dev png -drvopt text,smooth,24bit users have access to. For example, there are the bluesky computer modern fonts postscript type 1 format. We discussed those previously with regard to making nice-looking documentation, but it turns out they are useful for our plots as well. Those fonts appear in the /usr/share/texmf/fonts/type1/bluesky/ tree on my system, and are in the Debian package called tetex-extra, and they work fine with libfreetype (aside from the first 156 character issue). The only problem is they are split between a large number of files and switching between font files is currently rather clumsy because you have to set the PLPLOT_SYMBOL_FONT environment variable each time. (ToDo, use a modern font configuration system such as Keith Packard's fontconfig that is available with X and which serves as a user-friendly front-end for libfreetype.) Anyhow, despite much sampling of fonts I haven't yet found the symbol and Greek character font files I need yet in the bluesky tree. I know the symbols I need must be somewhere there since computer modern fonts are extraordinarily comprehensive and satisfy almost all Math needs. Perhaps what I need is hidden from me by the current limit of the first 156 characters. Another possibility that is accessible using libfreetype is truetype (as opposed to the bluesky postscript type 1) computer modern fonts. I got these from http://www.mozilla.org/projects/mathml/fonts/bakoma/texcm-ttf.zip. as recommended by http://www.mozilla.org/projects/mathml/fonts/. They are licensed for free distribution (see http://www.mozilla.org/projects/mathml/fonts/bakoma/license.txt) so long as you don't redistribute them for money yourself. Anyhow, they seem better organized (from the perspective of our current method of accessing fonts using PLPLOT_SYMBOL_FONT), and with fewer blank characters in the first 156. So the cmsy10.ttf file, for example has a gradient symbol while the corresponding bluesky /usr/share/texmf/fonts/type1/bluesky/cm/cmsy10.pfb font file seems to have a blank in the same location. I have yet to find a freely accessible font file with Greek characters in the first 156 locations, but for my immediate publication needs Andrew has given me such a font file privately that does that. So I can work around all the current freetype problems for my next two publications, and therefore my immediate needs are taken care of. To summarize my recent experience, Hershey fonts are not acceptable for the png device because they look pretty awful for that inherently low-resolution device (typically 800x600 pixels). So that is why libfreetype support for -dev png is so important. My recent experience with that shows there is tremendous potential there for -dev png users (and in fact users of any device once the required simple code changes are made for each device driver) since there are so many excellent free fonts that are available via libfreetype. Nevertheless, there is also scope for improvement in the way the libfreetype fonts are organized for PLplot (see ToDo item above), and we also have to find and fix the current 156 character limit bug. 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 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: Maurice L. <mj...@ga...> - 2004-05-18 03:12:49
|
Alan W. Irwin writes: > ... > To summarize my recent experience, Hershey fonts are not acceptable for the > png device because they look pretty awful for that inherently low-resolution > device (typically 800x600 pixels). So that is why libfreetype support for > -dev png is so important. My recent experience with that shows there is > tremendous potential there for -dev png users (and in fact users of any > device once the required simple code changes are made for each device > driver) since there are so many excellent free fonts that are available via > libfreetype. Nevertheless, there is also scope for improvement in the way > the libfreetype fonts are organized for PLplot (see ToDo item above), and we > also have to find and fix the current 156 character limit bug. I don't know how straightforward this would be to implement, but it would sure be nice if the hershey font specification e.g. #gD for capital Greek Delta (to use the recent example) could be seamlessly mapped onto the appropriate character in the alternate font set. Could handle sub/super scripts in a compatible way too, shifting position & size appropriately before printing char. This would make it fantastically simpler for the end user to switch between different fonts. (not that I have time to do it myself..) -- Maurice LeBrun |
|
From: Alan W. I. <ir...@be...> - 2004-05-18 05:16:32
|
On 2004-05-17 22:12-0500 Maurice LeBrun wrote: > Alan W. Irwin writes: > > ... > > To summarize my recent experience, Hershey fonts are not acceptable for the > > png device because they look pretty awful for that inherently low-resolution > > device (typically 800x600 pixels). So that is why libfreetype support for > > -dev png is so important. My recent experience with that shows there is > > tremendous potential there for -dev png users (and in fact users of any > > device once the required simple code changes are made for each device > > driver) since there are so many excellent free fonts that are available via > > libfreetype. Nevertheless, there is also scope for improvement in the way > > the libfreetype fonts are organized for PLplot (see ToDo item above), and we > > also have to find and fix the current 156 character limit bug. > > I don't know how straightforward this would be to implement, but it would sure > be nice if the hershey font specification e.g. #gD for capital Greek Delta (to > use the recent example) could be seamlessly mapped onto the appropriate > character in the alternate font set. Could handle sub/super scripts in a > compatible way too, shifting position & size appropriately before printing > char. This would make it fantastically simpler for the end user to switch > between different fonts. I agree. However, I believe greek letters tend to be in the same positions as for the Hershey fonts so that may not be a problem (at least for some fonts). At least this was the case (e.g., #gD just worked) for the publically inaccessble truetype font file that Andrew Roach gave to me as a stopgap measure so I could get my papers out. Also, for Arial.ttf the default MS core font corresponding to plfont(1), subscripting (and presumably superscripting although I haven't tried it) works fine, and I also presume it will work fine for plfont(2), plfont(3), and plfont(4), corresponding by default on Unix/Linux systems to the MS core fonts "Times_New_Roman.ttf", "Times_New_Roman_Italic.ttf", "Comic_Sans_MS.ttf". The real ordering problem is for symbols. We just have an embarrassment of riches for freely accessible type 1 postscript fonts and truetype fonts, and I expect the symbols for the various fonts don't come in any standard order. We likely will just have to live with that situation, and use some variant of x07c.c to find out what position corresponds to what symbol for a given font. Currently my variant of x07c.c uses "#g\xNN" (where NN is hexadecimal) syntax to explore the first 156 symbols of any font. Once the current 156 limit is overcome the #g method will only work up to the first 256 symbols in the font. Thus, eventually, I want to make sure the "#(NNNN)" method (where NNNN is decimal) will work as well. Currently the "#(NNNN)" method of producing symbols corresponding to arbitrary positions in the font table only works for 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 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-05-18 06:43:43
|
* Alan W. Irwin <ir...@be...> [2004-05-17 22:14]: > The real ordering problem is for symbols. We just have an embarrassment of > riches for freely accessible type 1 postscript fonts and truetype fonts, and > I expect the symbols for the various fonts don't come in any standard order. > We likely will just have to live with that situation, and use some variant > of x07c.c to find out what position corresponds to what symbol for a given > font. Currently my variant of x07c.c uses "#g\xNN" (where NN is hexadecimal) > syntax to explore the first 156 symbols of any font. Once the current 156 > limit is overcome the #g method will only work up to the first 256 symbols > in the font. Thus, eventually, I want to make sure the "#(NNNN)" method > (where NNNN is decimal) will work as well. Currently the "#(NNNN)" method > of producing symbols corresponding to arbitrary positions in the font table > only works for Hershey fonts. Let us try to not reinvent the wheel. The way to go here is to use Unicode UTF-8 (see http://www.unicode.org) for the encoding of the characters. So, we should make the API accept also Unicode strings as an alternative to the #-escaped strings. UTF-8 strings are easily detectable (use for instance libunicode, available everywhere) and the Freetype library is Unicode-aware. I am sure that almost all characters of the Hershey fonts have UTF-8 corresponding glyph numbers (see the glyph tables at http://www.unicode.org/charts/). -- Rafael |
|
From: Andrew R. <aro...@ya...> - 2004-05-18 12:05:15
|
At 08:43 AM 18/05/2004 +0200, you wrote: >* Alan W. Irwin <ir...@be...> [2004-05-17 22:14]: > > > The real ordering problem is for symbols. We just have an embarrassment of > > riches for freely accessible type 1 postscript fonts and truetype > fonts, and > > I expect the symbols for the various fonts don't come in any standard > order. In *theory* they should. Practice is another thing naturally... > > We likely will just have to live with that situation, and use some variant > > of x07c.c to find out what position corresponds to what symbol for a given > > font. Currently my variant of x07c.c uses "#g\xNN" (where NN is > hexadecimal) > > syntax to explore the first 156 symbols of any font. Once the current 156 > > limit is overcome the #g method will only work up to the first 256 symbols > > in the font. Thus, eventually, I want to make sure the "#(NNNN)" method > > (where NNNN is decimal) will work as well. Currently the "#(NNNN)" method > > of producing symbols corresponding to arbitrary positions in the font table > > only works for Hershey fonts. > >Let us try to not reinvent the wheel. The way to go here is to use Unicode >UTF-8 (see http://www.unicode.org) for the encoding of the characters. So, >we should make the API accept also Unicode strings as an alternative to the >#-escaped strings. UTF-8 strings are easily detectable (use for instance >libunicode, available everywhere) and the Freetype library is Unicode-aware. > >I am sure that almost all characters of the Hershey fonts have UTF-8 >corresponding glyph numbers (see the glyph tables at >http://www.unicode.org/charts/). I agree with Rafael, and believe unicode is the way to go long term - it's only an accident of 1980s 8 bit architecture we are stuck with ASCII's 256 characters. Translating between the Hershey fonts, unicode, then finding freetype compatible fonts with the symbols would be the interesting part of the exercise. -Andrew |
|
From: Rafael L. <rla...@us...> - 2004-05-18 17:25:20
Attachments:
plunicode.c
Makefile
|
* Andrew Roach <aro...@ya...> [2004-05-18 22:05]:
> I agree with Rafael, and believe unicode is the way to go long term - it's
> only an accident of 1980s 8 bit architecture we are stuck with ASCII's 256
> characters. Translating between the Hershey fonts, unicode, then finding
> freetype compatible fonts with the symbols would be the interesting part of
> the exercise.
In practical terms, we will have to make the functions pllab, plmtex, and
plptex become Unicode-aware. (N.B. : the remaining problem is with plsym,
which retains the semantics of the Hershey encoding.) This should not be
very complicated. For instance, the following call in x03c.c:
plmtex("t", 2.0, 0.5, 0.5, "#frPLplot Example 3 - r(#gh)=sin 5#gh");
would become:
plmtex("t", 2.0, 0.5, 0.5, "#frPLplot Example 3 - r(θ)=sin 5θ");
where the funny sequence of 8-bit characters "θ" means "the lower-case
greek letter theta". (Just cut & paste the line above, put it into a file
and open the file in a Web browser with character coding set to Unicode and
you will see a nice "theta"; at least, it works with my Mozilla 1.6.)
Of course, the old method would still be valid, and escaped sequences #g*
would be converted to the equivalent Unicode sequences.
To prove that it is really simple to use Unicode nowadays, I prepared a C
program using libunicode that decodes the string above. It is attached
below along with its Makefile. If you have the libunicode-dev package
installed (in Debian, at least), just type make and you will see:
$ make
gcc `unicode-config --libs --cflags` plunicode.c -o plunicode
./plunicode
UTF-8 decoding of string: "#frPLplot Example 3 - r(θ)=sin 5θ"
1: 35
2: 102
3: 114
4: 80
5: 76
6: 112
7: 108
8: 111
9: 116
10: 32
11: 69
12: 120
13: 97
14: 109
15: 112
16: 108
17: 101
18: 32
19: 51
20: 32
21: 45
22: 32
23: 114
24: 40
25: 952
26: 41
27: 61
28: 115
29: 105
30: 110
31: 32
32: 53
33: 952
The characters at positions 25 and 33 have the code number 952. This is
indeed the code for the lower-case greek theta (0x03B8), according to the
Unicode chart for the Greek glyphs
(http://www.unicode.org/charts/PDF/U0370.pdf).
The PLplot core routines would do different things with the Unicode
characters: either sending it directly to be plotted when using an
Unicode-aware driver (like gd with Unicode fonts), or lookup into a table
Unicode->Hershey and proceed with the plotting as it is the case today.
--
Rafael
|
|
From: Andrew R. <aro...@ya...> - 2004-05-19 04:06:41
|
At 07:25 PM 18/05/2004 +0200, you wrote:
>In practical terms, we will have to make the functions pllab, plmtex, and
>plptex become Unicode-aware. (N.B. : the remaining problem is with plsym,
>which retains the semantics of the Hershey encoding.) This should not be
>very complicated. For instance, the following call in x03c.c:
> plmtex("t", 2.0, 0.5, 0.5, "#frPLplot Example 3 - r(#gh)=3Dsin 5#gh");
>
>would become:
>
> plmtex("t", 2.0, 0.5, 0.5, "#frPLplot Example 3 - r(=CE=B8)=3Dsin=
5=CE=B8");
Flying completely off the top of my head here, but assuming we make those=20
functions unicode aware, there should be no need to add anything in the=20
metafile format - as long as the metafile was being replayed to unicode=20
aware plrender, all should be well. A non unicode plrender would just put a=
=20
funny character out instead, which would at least not be fatal.
>where the funny sequence of 8-bit characters "=CE=B8" means "the lower-case
>greek letter theta". (Just cut & paste the line above, put it into a file
>and open the file in a Web browser with character coding set to Unicode and
>you will see a nice "theta"; at least, it works with my Mozilla 1.6.)
I gotta say, that is very cool trick (and works with IE too); but I think=20
that using the "#g" syntax is easier on the brain. I know which I would be=
=20
using ;-).
>To prove that it is really simple to use Unicode nowadays, I prepared a C
>program using libunicode that decodes the string above. It is attached
>below along with its Makefile. If you have the libunicode-dev package
>installed (in Debian, at least), just type make and you will see:
That is elegance and simplicity !
Can you think of any other issues that might get in the way of adding=20
unicode support ? I think the biggest hurdle would be getting a=20
Hershey/unicode translation table.
-Andrew
|
|
From: Rafael L. <rla...@us...> - 2004-05-19 06:48:27
|
* Andrew Roach <aro...@ya...> [2004-05-19 14:06]: > I gotta say, that is very cool trick (and works with IE too); but I think > that using the "#g" syntax is easier on the brain. I know which I would be > using ;-). Agreed. Unless you have an Unicode-supported editor (my Emacs-mule does it, for instance), it is impractical to enter Unicode characters. Related to that, nothing prevents us of implementing the #(NNNN) escape sequence proposed in this thread. We can even implement this right now, without the Unicode support. However, I would prefer that the NNNN number refers to the Unicode encoding, and not to the position of the glyphs in the Harshey font. This brings us to your point: > Can you think of any other issues that might get in the way of adding > unicode support ? I think the biggest hurdle would be getting a > Hershey/unicode translation table. Yes, this would be the only single hurdle in the implementation, but it is absolutely necessary. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2004-05-19 16:28:48
|
On 2004-05-19 08:47+0200 Rafael Laboissiere wrote: > * Andrew Roach <aro...@ya...> [2004-05-19 14:06]: > > Can you think of any other issues that might get in the way of adding > > unicode support ? I think the biggest hurdle would be getting a > > Hershey/unicode translation table. > > Yes, this would be the only single hurdle in the implementation, but it is > absolutely necessary. Andrew, I assume getting that translation table right consists of comparing plots of the symbols for a unicode ordered font versus the Hershey font and adjusting the translation table to make the Hershey font symbol order come out the same. I can certainly help with that tedious aspect of the project. 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 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-05-19 19:23:40
|
* Alan W. Irwin <ir...@be...> [2004-05-19 09:28]: > On 2004-05-19 08:47+0200 Rafael Laboissiere wrote: > > > * Andrew Roach <aro...@ya...> [2004-05-19 14:06]: > > > > Can you think of any other issues that might get in the way of adding > > > unicode support ? I think the biggest hurdle would be getting a > > > Hershey/unicode translation table. > > > > Yes, this would be the only single hurdle in the implementation, but it is > > absolutely necessary. > > Andrew, I assume getting that translation table right consists of comparing > plots of the symbols for a unicode ordered font versus the Hershey font and > adjusting the translation table to make the Hershey font symbol order come > out the same. I can certainly help with that tedious aspect of the > project. Thanks for stepping forward. Please, do it. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2004-05-18 15:46:01
|
On 2004-05-18 22:05+1000 Andrew Roach wrote: > I agree with Rafael, and believe unicode is the way to go long term - it's > only an accident of 1980s 8 bit architecture we are stuck with ASCII's 256 > characters. Translating between the Hershey fonts, unicode, then finding > freetype compatible fonts with the symbols would be the interesting part of > the exercise. I also agree unicode is a worthwhile goal, and I hope you have time to look into it. If moving to unicode can be done in the short-term, then fixing the #(NNNN) approach becomes moot. But if unicode is going to be a long-term fix, then I hope you also look into the #(NNNN) approach to see if there is a simple fix to make it work with non-Hershey fonts. The short-term problem is there is currently no way to use more than the first 256 characters in any font file, and I don't want that to turn into a long-term problem. BTW, your recent cvs fix to change the 156 character limit to 256 works great. Thanks very much! But I also hope we can soon go through the 256 character limit 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 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 __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X