From: Alan W. I. <ir...@be...> - 2004-09-06 18:18:11
|
I just tried the following experiment: ./x08c -dev pstex -o test.pstex -fam -fsiz 2k pstex2eps test.pstex.1 gv test.pstex.1.eps and all the axes have bad-looking labels because of 3D rotation problems with the pstex device. I am not sure whether it is worth fixing this device since few are using it (or if anybody is using it, they haven't complained about the above bad-looking results). For those who just want good-looking font results, another option is using the devices (png, jpeg, gif) associated with the gd device driver and the -drvopt text or -drvopt text,smooth command-line options to use plfreetype (as a front-end to libfreetype2) to specify the fonts. plfreetype gives good-looking png results for my research plots. However, specification of mathematical symbols and non-English language symbols within PLplot is difficult for general true-type fonts until we can introduce unicode support into PLplot. As I understand it, Andrew (Roach) was close to getting that done this summer, but then other PLplot interests (such as the new gif device) distracted him. 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? 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-09-06 21:16:55
Attachments:
affine.ps
|
* 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. A better approach would be to use the native affine transformation of the Postscript language to do arbritrary shear/rotation of characters. Look at the very simple PS file attached below that I wrote to illustrate my point. Implementing this idea may imply in substantial changes in the core functions of PLplot. A new PLESC_HAS_AFFINE escape code (let's say) could be introduced and used by drivers that claim to be able to do arbitrary rotation and shear of graphical objects (like PostScript does). This is a great project for someone with plenty of free time, which is not my case... -- Rafael |
From: Andrew R. <aro...@ya...> - 2004-09-07 03:27:34
|
At 11:14 AM 6/09/2004 -0700, Alan W. Irwin wrote: >into PLplot. As I understand it, Andrew (Roach) was close to getting that >done this summer, but then other PLplot interests (such as the new gif >device) distracted him. It is still sitting there on the back burner (don't give up yet). My "quick fix" effort was sunk though by some minor problems with the opensource unicode library. >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? Those documents are pretty up to date and work 100% ok with non-interactive devices that do not require refreshes. Any driver that uses bitmaps and has a setpixel function should be able to support freetype with the addition of a few lines of code. In adding freetype support to the wingcc driver I did need to expand the freetype driver a little by adding a local text cache. When a refresh command is requested (usually by windows) within the wingcc driver, I simply replayed the plot buffer and redraw everything; unfortunately, the text was not buffered because plplots own buffer only stores draw commands - hence the need for the local text buffer. The changes (from the above docs) needed to make a device driver support the text cache are minimal, as freetype itself decides if text buffering is required. In the case of wingcc, before I added the text cache the replot function was: if (dev->waiting==1) { plRemakePlot(pls); } then after it became: if (dev->waiting==1) { plRemakePlot(pls); #ifdef HAVE_FREETYPE pl_RemakeFreeType_text_from_buffer(pls); #endif } So in short, if you wanted to add freetype to an interactive bitmap terminal that needed cachingof plot commands, you would need to add just one extra line of code beyond what is currently in the documentation. I'll update the docs to reflect this, but if anyone were interested in adding support to an interactive device, look at wingcc.c rather than gd.c. At 11:16 PM 6/09/2004 +0200, Rafael Laboissiere wrote: >A better approach would be to use the native affine transformation of the >Postscript language to do arbritrary shear/rotation of characters. Look at >the very simple PS file attached below that I wrote to illustrate my point. >Implementing this idea may imply in substantial changes in the core >functions of PLplot. A new PLESC_HAS_AFFINE escape code (let's say) could >be introduced and used by drivers that claim to be able to do arbitrary >rotation and shear of graphical objects (like PostScript does). I do not think we really need a "PLESC_HAS_AFFINE" escape code ? Transformations for text are stored inside "EscText *args" in all text drawing functions anyway, so it is there for anything that wants it. plfreetype simply interrogates these parameters to find out what transformation/shearing is required. -Andrew Roach |
From: Rafael L. <rla...@us...> - 2004-09-07 07:06:52
|
* Andrew Roach <aro...@ya...> [2004-09-07 13:27]: > At 11:16 PM 6/09/2004 +0200, Rafael Laboissiere wrote: > >A better approach would be to use the native affine transformation of the > >Postscript language to do arbritrary shear/rotation of characters. Look at > >the very simple PS file attached below that I wrote to illustrate my point. > >Implementing this idea may imply in substantial changes in the core > >functions of PLplot. A new PLESC_HAS_AFFINE escape code (let's say) could > >be introduced and used by drivers that claim to be able to do arbitrary > >rotation and shear of graphical objects (like PostScript does). > > I do not think we really need a "PLESC_HAS_AFFINE" escape code ? > Transformations for text are stored inside "EscText *args" in all text > drawing functions anyway, so it is there for anything that wants it. > plfreetype simply interrogates these parameters to find out what > transformation/shearing is required. Great, that may simplify a lot the use of native affine transformation in the ps driver. BTW, I just notice from the examples (like x18c) that the ps driver does already rotate the axis labels in 3D plots. We need only add shear transformation and the results for the ps driver with "-drvopt text" will look quite similar to that with the Hershey fonts. I think that it would be impossible to implement generic shear transformation of characters in the pstex driver, because it uses the TeX machinery to render text and TeX does not allow (easily) arbitrary transformation of the fonts (besides scaling and rotation). -- Rafael |
From: <jc...@fe...> - 2004-09-07 19:10:55
|
On Tuesday 07 September 2004 04:27, Andrew Roach wrote: | At 11:14 AM 6/09/2004 -0700, Alan W. Irwin wrote: ... | In adding freetype support to the wingcc driver I did need to expand | the freetype driver a little by adding a local text cache. When a | refresh command is requested (usually by windows) within the wingcc | driver, I simply replayed the plot buffer and redraw everything; | unfortunately, the text was not buffered because plplots own buffer | only stores draw commands Yes, I miss that when I wrote the PLESC_HAS_TEXT extension, and latter didn't find motivation to finish it. Roughly, what is really needed is to store the text info into the plot buffer. In src/plbuf.c, in function plbuf_esc(), add a case PLESC_HAS_TEXT and in rdbuf_esc() do the same. Some small changes might be needed in plcore.c also. | - hence the need for the local text buffer. | The changes (from the above docs) needed to make a device driver | support the text cache are minimal, as freetype itself decides if | text buffering is required. In the case of wingcc, before I added the | text cache the replot function was: | | if (dev->waiting==1) | { | plRemakePlot(pls); | } | then after it became: | | if (dev->waiting==1) | { | plRemakePlot(pls); | #ifdef HAVE_FREETYPE | pl_RemakeFreeType_text_from_buffer(pls); | #endif | } With the above changes this wouldn't be needed. If the above is implemented, than at plcore.c:plP_text() if (plsc->plbuf_write) plbuf_esc(plsc, PLESC_HAS_TEXT, &args); would store the text info in the plot buffer and plRemakePlot() would read and plot it from the buffer. But I will not do that, so please feel free to do it yourself :)) | So in short, if you wanted to add freetype to an interactive bitmap | terminal that needed cachingof plot commands, you would need to add | just one extra line of code beyond what is currently in the | documentation. I'll update the docs to reflect this, but if anyone | were interested in adding support to an interactive device, look at | wingcc.c rather than gd.c. The iterative driver I think would benefice from freetype is the xwin driver. I have already thought of that, and it didn't seem to difficult to do, as most support is already in plfreetype.c. But my analysis was superficial, and I don't have the time | At 11:16 PM 6/09/2004 +0200, Rafael Laboissiere wrote: | >A better approach would be to use the native affine transformation | > of the Postscript language to do arbritrary shear/rotation of | > characters. Look at the very simple PS file attached below that I | > wrote to illustrate my point. Implementing this idea may imply in | > substantial changes in the core functions of PLplot. A new | > PLESC_HAS_AFFINE escape code (let's say) could be introduced and | > used by drivers that claim to be able to do arbitrary rotation and | > shear of graphical objects (like PostScript does). | | I do not think we really need a "PLESC_HAS_AFFINE" escape code ? | Transformations for text are stored inside "EscText *args" in all | text drawing functions anyway, so it is there for anything that wants | it. plfreetype simply interrogates these parameters to find out what | transformation/shearing is required. But sometimes, I don't know why, it is not possible to fully recover the original information -- that's the reason why in 3D the text is wrongly rotated/sheared in the ps driver. By the way, the ps driver uses two methods to rotate text, accessible using -drvopt text=1|2, the default being 1. Method 2 enables shearing as well, but is incomplete. The pstex driver suffers from the same problem as the ps one, and in addition can't have rotation/shearing/continuous justification, as latex don't support it (as far as I know). The pstex driver main feature is the ability to use the latex math capabilities. Joao | | -Andrew Roach | | | | | | | ------------------------------------------------------- | This SF.Net email is sponsored by BEA Weblogic Workshop | FREE Java Enterprise J2EE developer tools! | Get your free copy of BEA WebLogic Workshop 8.1 today. | http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <aro...@ya...> - 2004-09-08 04:15:57
|
At 08:09 PM 7/09/2004 +0100, Jo=E3o Cardoso wrote: >Roughly, what is really needed is to store the text info into the plot >buffer. >In src/plbuf.c, in function plbuf_esc(), add a case PLESC_HAS_TEXT and >in rdbuf_esc() do the same. Some small changes might be needed in >plcore.c also. The thought crossed my mind about adding the text to plbuf, but I was a=20 little worried about backwards compatibility with the metafile format (it=20 is the same as plbuf isn't it ?), so thought I would go for the local text= =20 cache which had zero impact on other parts of the library. Ideally, ALL text should be saved to the buffer, regardless of whether the= =20 driver supported it's own text drawing capabilities; that way if you=20 replayed a metafile to a device that supported freetype (or any other=20 self-rendering), the text would be drawn using freetype. Under this model,= =20 the text being drawn in a regular driver would be parsed to the text=20 commands and converted to vectors. This approach would, I assume, make=20 backwards compatibility with metafiles a problem since the new way of=20 storing text would fail on old versions of plrender. But could we safely=20 assume that since people had built and installed plplot on their system,=20 their plrender was always up to date anyway so this would be a non-issue ? >| So in short, if you wanted to add freetype to an interactive bitmap >| terminal that needed cachingof plot commands, you would need to add >| just one extra line of code beyond what is currently in the >| documentation. I'll update the docs to reflect this, but if anyone >| were interested in adding support to an interactive device, look at >| wingcc.c rather than gd.c. > >The iterative driver I think would benefice from freetype is the xwin >driver. I have already thought of that, and it didn't seem to difficult >to do, as most support is already in plfreetype.c. But my analysis was >superficial, and I don't have the time The hardest part comes with the palette support when using the text=20 smoothing. The wingcc driver took a giant leap of faith in this department= =20 by ASSUMING a 24 bit driver, so did not worry about extending the palette.= =20 This assumption, though extreme, should be safe on pretty much any windows= =20 machine assembled in the last 10 years or so. I don't think you could make= =20 the same assumption about the xwin driver (that everyone would have 24=20 bit), so you probably would have to deal with the palette more carefully. -Andrew Roach |
From: <jc...@fe...> - 2004-09-08 17:34:06
|
On Wednesday 08 September 2004 05:15, Andrew Roach wrote: | At 08:09 PM 7/09/2004 +0100, Jo=E3o Cardoso wrote: | >Roughly, what is really needed is to store the text info into the | > plot buffer. | >In src/plbuf.c, in function plbuf_esc(), add a case PLESC_HAS_TEXT | > and in rdbuf_esc() do the same. Some small changes might be needed | > in plcore.c also. | | The thought crossed my mind about adding the text to plbuf, but I was | a little worried about backwards compatibility with the metafile | format (it is the same as plbuf isn't it ?),=20 But backward compatibility would be maintained, as existing metafiles=20 would be properly read and displayed; new metafiles couldn't be read by=20 old plplot apps, but that kind of compatibility is most of the time not=20 required or even possible. | Ideally, ALL text should be saved to the buffer, regardless of | whether the driver supported it's own text drawing capabilities; that | way if you replayed a metafile to a device that supported freetype | (or any other self-rendering), the text would be drawn using | freetype. Yes, of course. | Under this model, the text being drawn in a regular driver=20 | would be parsed to the text commands and converted to vectors. This | approach would, I assume, make backwards compatibility with metafiles | a problem since the new way of storing text would fail on old | versions of plrender. I don't think this to be a problem. =2E.. | >The iterative driver I think would benefice from freetype is the | > xwin driver. I have already thought of that, and it didn't seem to | > difficult to do, as most support is already in plfreetype.c. But my | > analysis was superficial, and I don't have the time | | The hardest part comes with the palette support when using the text | smoothing. And if one forgets smoothing? Wouldn't the implementation be much=20 simpler? Smoothing is after all an option for the gd family of drivers,=20 and we don't need to support it for the xwin driver.=20 | The wingcc driver took a giant leap of faith in this=20 | department by ASSUMING a 24 bit driver, so did not worry about | extending the palette. You mean the X11 xserver color pallete, not the plplot cmap1 pallete,=20 right? Why isn't a 16 bits truecolor X display enough? The code in gd.c=20 seems to use 64 graylevels be default, isn't that available on a 16bits=20 truecolor xserver? Sorry for the ignorance :( Joao | This assumption, though extreme, should be=20 | safe on pretty much any windows machine assembled in the last 10 | years or so. I don't think you could make the same assumption about | the xwin driver (that everyone would have 24 bit), so you probably | would have to deal with the palette more carefully. | | -Andrew Roach | | | | ------------------------------------------------------- | This SF.Net email is sponsored by BEA Weblogic Workshop | FREE Java Enterprise J2EE developer tools! | Get your free copy of BEA WebLogic Workshop 8.1 today. | http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <aro...@ya...> - 2004-09-09 04:25:00
|
At 06:32 PM 8/09/2004 +0100, Jo=E3o Cardoso wrote: >| >The iterative driver I think would benefice from freetype is the >| > xwin driver. I have already thought of that, and it didn't seem to >| > difficult to do, as most support is already in plfreetype.c. But my >| > analysis was superficial, and I don't have the time >| >| The hardest part comes with the palette support when using the text >| smoothing. > >And if one forgets smoothing? Wouldn't the implementation be much >simpler? Smoothing is after all an option for the gd family of drivers, >and we don't need to support it for the xwin driver. Without smoothing, it is a snap. Smoothing is used by the wingcc driver too. Believe me, it really shines=20 when used on interactive terms, especially when you use smaller windows,=20 have small fonts, or do multiple plots on a page. With smoothing and 4=20 plots a page, you can still read all the text easily. >| The wingcc driver took a giant leap of faith in this >| department by ASSUMING a 24 bit driver, so did not worry about >| extending the palette. > >You mean the X11 xserver color pallete, not the plplot cmap1 pallete, >right? Yes. >Why isn't a 16 bits truecolor X display enough? In practice, that would be more than enough to get the job done. Can we=20 make the assumption that all X displays are going to be 16 bit ? I am not=20 debating the point here - I just do not know. When I looked at the xwin=20 code, there seemed to be a lot of logic to handle displays with small=20 palettes. If we can, then you let plplot handle it's own cmap1 cmap0=20 palettes, and let freetype automagically smooth the text, taking what=20 colours it needs, as it needs them. > The code in gd.c >seems to use 64 graylevels be default, isn't that available on a 16bits >truecolor xserver? Sorry for the ignorance :( Yes, it should be available. Even if the number of greys used for smoothing= =20 was extended beyond 64**, 99% of the time it would be accommodated in a 16= =20 bit display driver. **(in theory, you can go as high as 256; in practice, you cant tell the=20 difference; in reality rarely no more than about 12 ever seem to get used). -Andrew |
From: <jc...@fe...> - 2004-09-09 13:48:44
|
On Thursday 09 September 2004 05:24, Andrew Roach wrote: | At 06:32 PM 8/09/2004 +0100, Jo=E3o Cardoso wrote: =2E.. | >| The wingcc driver took a giant leap of faith in this | >| department by ASSUMING a 24 bit driver, so did not worry about | >| extending the palette. =2E.. | >Why isn't a 16 bits truecolor X display enough? | | In practice, that would be more than enough to get the job done. Can | we make the assumption that all X displays are going to be 16 bit ? I can assume it the same way as you assumed 24bits in gcwin. All=20 current linux distros must use 16/24 bits as default; and Xservers (is=20 that still a business?) generally have xservers that support multiple=20 color types and depths. | am not debating the point here - I just do not know. When I looked at | the xwin code, there seemed to be a lot of logic to handle displays | with small palettes. That's legacy code. We also have a laserjet II driver! | If we can, then you let plplot handle it's own=20 | cmap1 cmap0 palettes, and let freetype automagically smooth the text, | taking what colours it needs, as it needs them. OK, thanks for the info. If/when I have spare time I will try that. Joao | -Andrew | | | | ------------------------------------------------------- | This SF.Net email is sponsored by BEA Weblogic Workshop | FREE Java Enterprise J2EE developer tools! | Get your free copy of BEA WebLogic Workshop 8.1 today. | http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk | _______________________________________________ | Plplot-devel mailing list | Plp...@li... | https://lists.sourceforge.net/lists/listinfo/plplot-devel |