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 |