From: Alan W. I. <ir...@be...> - 2004-10-24 19:19:52
|
I forward a user's bug report below. He reports two issues with pstex.c. (1) pstex and ps have slightly (at the 0.8 per cent level) inconsistent text sizes, and this means for long plots text strings gradually become misaligned. (2) pstex does not accept empty strings. I have had no time to verify these problems for myself, but this user did give me an example showing how for long plots the text gradually gets misaligned because of problem 1 so I am sure the size inconsistency (and presumably also the empty string issue) are real problems with pstex.c. This user is only using pstex because he needs access to the nice fonts. But this device has never been documented, and the early promising development seems to have ground to a halt. Andrew (Roach), is it possible to use your freetype approach instead for ps.c to get nice-looking fonts for our psc and ps devices, and if so, how much work would be involved? 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 __________________________ ---------- Forwarded message ---------- Date: Thu, 30 Sep 2004 14:05:01 -0700 From: Bill Paxton <pa...@ki...> To: Alan W. Irwin <ir...@be...> Subject: Proper registration of text and graphics with pstex driver Hi Alan, It sounds like this is a dead issue for you guys, but I did track down the problem. The pstex driver tells TeX what the unitlength is for the picture, and this better agree with what the ps driver tells PostScript, or we'll get misaligned text. The ps driver sets up the unit length by doing a scale with values from ps.h, XSIZE and XPSSIZE, which gives 540/720 for unit length in PostScript. The pstex driver sets the unit length to be 72./25.4/pls->xpmm. Where pls->xpmm has been previously set by the ps driver to be YPSSIZE/LPAGE_X. YPSSIZE is ENLARGE*YSIZE. LPAGE_X is (PIXELS_X/VDPMM). VDPMM is DPMM*32. DPMM is 4. PIXELS_X is 32768. YSIZE is 720. ENLARGE is 5. Crank all this and you finally get a unitsize from pstex of 0.201575 vs. unitsize frm ps of 0.200000. When pstex is changed to calculate unitsize in the same way that ps does, the registration problem goes away. The change I made in pstex.c was in the plD_init_pstex procedure: fprintf(fp,"\\setlength{\\unitlength}{%fbp}%%\n", 72./25.4/pls->xpmm); Becomes fprintf(fp,"\\setlength{\\unitlength}{%fbp}%%\n", 1.0/ENLARGE); Heaven only knows what this change will cause to break elsewhere, but it seems to work for my test cases. Cheers, Bill P.S. TeX also seems to dislike getting blank strings, so proc_str in pstex should filter them out. Try calling pllab("","","") to check it. |
From: Rafael L. <rla...@us...> - 2004-10-24 21:24:31
|
* Alan W. Irwin <ir...@be...> [2004-10-24 12:19]: > Andrew (Roach), is it possible to use your freetype approach instead for > ps.c to get nice-looking fonts for our psc and ps devices, and if so, how > much work would be involved? You already asked this question in plplot-devel and below is the answer that I gave to you: * Rafael Laboissiere <rla...@us...> [2004-09-06 23:16]: > * Alan W. Irwin <ir...@be...> [2004-09-06 11:14]: > > > Also, I would like to encourage those who are familiar with writing PLplot > > device drivers to extend our ps device driver to use plfreetype since that > > is one of our most heavily used device drivers. Andrew, how difficult would > > this be? Is the documentation at > > http://plplot.sourceforge.net/docbook-manual/plplot-html-5.3.1/freetype-notes.html > > reasonably up to date for the steps you would have to take? > > I am not sure that using the plfreetype support in the ps-related drivers is > a good idea. plfreetype.c implements a bitmap-oriented rendering of the > fonts, while the ps driver is vectorized. Although it could be possible to > implement your idea, it would result in two drawbacks: first, bitmaps would > be included in the resulting PS file for each character rendered, perhaps > with an unacceptable increase in size. Second (and worst), the result could > look awful. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-10-25 01:54:16
|
On 2004-10-24 23:24+0200 Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-10-24 12:19]: > >> Andrew (Roach), is it possible to use your freetype approach instead for >> ps.c to get nice-looking fonts for our psc and ps devices, and if so, how >> much work would be involved? > > You already asked this question in plplot-devel and below is the answer that > I gave to you: > > * Rafael Laboissiere <rla...@us...> [2004-09-06 23:16]: >> I am not sure that using the plfreetype support in the ps-related drivers is >> a good idea. plfreetype.c implements a bitmap-oriented rendering of the >> fonts, while the ps driver is vectorized. Although it could be possible to >> implement your idea, it would result in two drawbacks: first, bitmaps would >> be included in the resulting PS file for each character rendered, perhaps >> with an unacceptable increase in size. Second (and worst), the result could >> look awful. The only way to answer such negative speculations is to try an implementation to see whether the issues raised are important or not. Thus, I repeat the question directed to Andrew above. If it turns out only a reasonable amount of work is required to extend the freetype approach to ps.c, then let's give it a try. If the postscript freetype results are as good as in the png and jpeg cases, then we will really have a nice advance for PLplot. The postscript device is one of our most important devices (postscript is the usual first choice for scientific publication), and the Hershey fonts we are currently limited to for that device are a real drawback compared to the nice-looking fonts that are available using the freetype approach. 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-10-25 07:45:54
|
* Alan W. Irwin <ir...@be...> [2004-10-24 18:54]: > The only way to answer such negative speculations is to try an > implementation to see whether the issues raised are important or not. I am not speculating. The Freetype rendering engine is bitmap oriented and cannot render characters in vector-drawing mode for publish-quality printing in PostScript. I would be mostly glad if you can prove me the contrary (in other words: show me the code, or get out of my way :-). Besides the technical difficulties of such approach (as pointed out by Andrew in another post), the results will indeed be disappointing. -- Rafael |
From: Andrew R. <and...@us...> - 2004-10-25 08:37:04
|
On Mon, Oct 25, 2004 at 09:45:51AM +0200, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2004-10-24 18:54]: > > > The only way to answer such negative speculations is to try an > > implementation to see whether the issues raised are important or not. > > I am not speculating. The Freetype rendering engine is bitmap oriented and > cannot render characters in vector-drawing mode for publish-quality printing > in PostScript. I would be mostly glad if you can prove me the contrary (in > other words: show me the code, or get out of my way :-). > > Besides the technical difficulties of such approach (as pointed out by > Andrew in another post), the results will indeed be disappointing. For postscript files I now always use the postscript font support rather than the plplot Hershey fonts. This always seems to produce nicer results. If we are going to fix the postscript driver maybe we should do it properly and extend the postscript font support to include other PS fonts. Of course my postscript knowledge is limited and this might be a big job... I'm willing to investigate though. Does anyone have any experience of this kind of thing? Andrew |
From: Andrew R. <aro...@ya...> - 2004-10-25 04:43:34
|
At 06:54 PM 24/10/2004 -0700, you wrote: >On 2004-10-24 23:24+0200 Rafael Laboissiere wrote: > >>* Alan W. Irwin <ir...@be...> [2004-10-24 12:19]: >> >>>Andrew (Roach), is it possible to use your freetype approach instead for >>>ps.c to get nice-looking fonts for our psc and ps devices, and if so, how >>>much work would be involved? >> >>You already asked this question in plplot-devel and below is the answer that >>I gave to you: >> >>* Rafael Laboissiere <rla...@us...> [2004-09-06 23:16]: >>>I am not sure that using the plfreetype support in the ps-related drivers is >>>a good idea. plfreetype.c implements a bitmap-oriented rendering of the >>>fonts, while the ps driver is vectorized. Although it could be possible to >>>implement your idea, it would result in two drawbacks: first, bitmaps would >>>be included in the resulting PS file for each character rendered, perhaps >>>with an unacceptable increase in size. Second (and worst), the result could >>>look awful. > >The only way to answer such negative speculations is to try an >implementation to see whether the issues raised are important or not. Thus, >I repeat the question directed to Andrew above. If it turns out only a >reasonable amount of work is required to extend the freetype approach to >ps.c, then let's give it a try. If the postscript freetype results are as >good as in the png and jpeg cases, then we will really have a nice advance >for PLplot. The postscript device is one of our most important devices >(postscript is the usual first choice for scientific publication), and the >Hershey fonts we are currently limited to for that device are a real >drawback compared to the nice-looking fonts that are available using the >freetype approach. I am not too familiar with all the capabilities of postscript files, and the ins and outs of them and especially programming them. I really would not know where to start with embedded a freetype generated bitmap. I agree with Rafael, that using freetype with the ps driver, the results would likely be disappointing, not to mention the difficulty in implementing due to the bitmap/vector mixing. A better approach would be to try and use postscripts in-built font rendering, and type-1 fonts to render nicer text. I do not know if postscript allows for true-type fonts. It might be easier to try and fix the progressive displacement in plstex, not to mention better quality, rather than trying to add bitmap support to the PS driver. -Andrew |
From: Alan W. I. <ir...@be...> - 2004-10-25 05:41:36
|
On 2004-10-25 14:40+1000 Andrew Roach wrote: > I am not too familiar with all the capabilities of postscript files, and the > ins and outs of them and especially programming them. I really would not > know where to start with embedded a freetype generated bitmap. Then it sounds like freetype support in our ps device drivers is going to be a difficult task. > I agree with Rafael, that using freetype with the ps driver, the results > would likely be disappointing, not to mention the difficulty in implementing > due to the bitmap/vector mixing. I am pretty sure postscript fully supports bitmapped fonts (as in the original computer modern fonts used by Latex which produced such good looking postscript results even in the 80's long before truetype versions of computer modern fonts came out). Nevertheless, the difficulty of the task caused by our joint lack of knowledge about postscript is a real showstopper so I guess my dream of freetype for our postscript device driver is a lost cause. Too bad! > A better approach would be to try and use > postscripts in-built font rendering, and type-1 fonts to render nicer text. I > do not know if postscript allows for true-type fonts. It might be easier to > try and fix the progressive displacement in plstex, not to mention better > quality, rather than trying to add bitmap support to the PS driver. Since freetype support in our postscript driver is apparently not on, I would now encourage documenting the pstex device driver and starting to fully support it since this is a viable alternative for getting access to extremely nice-looking fonts with postscript. So that leads back to the original topic. Is somebody with pstex knowledge prepared to step forward to evaluate and fix these problems and also document pstex? 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-10-25 12:18:46
|
* Alan W. Irwin <ir...@be...> [2004-10-24 22:41]: > Then it sounds like freetype support in our ps device drivers is going > to be a difficult task. Instead of using the bitmap approach of plfreetype.c, we might take another road for adding freetype support to the PS drivers. I googled a little bit and discovered the wprint project (http://ttt.esperanto.org.uy/programoj/angle/wprint.html). In this project, there is a source file called wprint-ft2.c in which the outline of TrueType 2 fonts obtained through the freetype library are transformed directly into curveto commands in PostScript. The curveto PS primitive implements Bezier curves, which allow smooth contour rendering. To implement this idea in PLplot, we could first introduce a new primitive plotting "object" in the core. Let us call it bpath (for Bezier path). A bpath would be similar to a polyline, but each vertex would be actually a control point for the cubic curve. Next, the drivers have to me modified to be capable of rendering bpaths. That should not be difficult to do, since the algorithm for rendering Bezier paths is efficient and largely published. At least for the gnome driver, this would be straightforward, since the GnomeCanvas can render bpaths directly. Then comes the fun: using the same approach as wprint's, we could add freetype support to the text producing routines in PLplot, but using the glyph outlines instead of the current bitmap approach. There will be many advantage in using Bezier paths for font rendering in PLplot, among them: (1) text could be zoomed in nicely; (2) there would be a direct correspondence between screen (or bitmap) oriented and the PostScript (and PDF) text rendering; (3) Unicode support would be added for free. This could be a nice project for PLplot. I hope there would be more people interested in this, since I could not tackle this alone. -- Rafael |
From: Alan W. I. <ir...@be...> - 2004-11-07 17:53:20
|
On 2004-10-24 12:19-0700 Alan W. Irwin wrote: > ---------- Forwarded message ---------- > Date: Thu, 30 Sep 2004 14:05:01 -0700 > From: Bill Paxton <pa...@ki...> > [...] The pstex driver tells TeX what the unitlength is for the > picture, and this better agree with what the ps driver tells PostScript, or > we'll get misaligned text. The ps driver sets up the unit length by doing a > scale with values from ps.h, XSIZE and XPSSIZE, which gives 540/720 for > unit length in PostScript. The pstex driver sets the unit length to be > 72./25.4/pls->xpmm. Where pls->xpmm has been previously set by the ps > driver to be YPSSIZE/LPAGE_X. YPSSIZE is ENLARGE*YSIZE. LPAGE_X is > (PIXELS_X/VDPMM). VDPMM is DPMM*32. DPMM is 4. PIXELS_X is 32768. YSIZE > is 720. ENLARGE is 5. Crank all this and you finally get a unitsize from > pstex of 0.201575 vs. unitsize frm ps of 0.200000. When pstex is changed > to calculate unitsize in the same way that ps does, the registration problem > goes away. The change I made in pstex.c was in the plD_init_pstex > procedure: > > fprintf(fp,"\\setlength{\\unitlength}{%fbp}%%\n", 72./25.4/pls->xpmm); > > Becomes > > fprintf(fp,"\\setlength{\\unitlength}{%fbp}%%\n", 1.0/ENLARGE); > > Heaven only knows what this change will cause to break elsewhere, but it > seems to work for my test cases. This morning I almost applied the one-line fix above, but I checked the code looking for "25.4", and the factors 72./25.4/pls->xpmm and 72./25.4/pls->ypmm appear in a lot of places in the pstex.c code. Thus, I believe it is unlikely Bill's fix is complete for solving the registration problems for this device so I decided to make no changes. I suggest instead, whoever fixes this look for "25.4" and carefully analyze (as in Bill's detailed analysis above for the one instance) what the factor should be in each case. Probably, it should be 1.0/ENLARGE, but I don't want to do that change blindly without following Bill's analysis in each case, and unfortunately I don't have time to do that at the moment. If somebody else wants to step forward now, be my guest, but otherwise, I will put this on my ToDo list to deal with when I have more time for PLplot in the long term. > > > P.S. TeX also seems to dislike getting blank strings, so proc_str in pstex > should filter them out. Try calling pllab("","","") to check it. I think we should pursue a multi-prong approach here; on the one hand I hope somebody fixes these known problems with pstex.c in the short term (or I will do it in the long term), and in the long term I hope Rafael, Andrew Ross, and Andrew Roach (all of whom expressed some interest) can agree on and implement a solution for making non-Hershey fonts directly accessible to ps.c. I would also be willing to help out with such a project if somebody else will organize it. In my view, such a project is really important for PLplot because ps.c is one of our most heavily used devices, and the Hershey fonts that we are limited to now for that device just don't cut it any more compared to what our competitors are doing. Case in point: I was showing PLplot results to a colleague of mine a couple of months ago, and he lost interest in PLplot as soon as he saw 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 __________________________ |