Re: [Plplot-devel] Status of the svg device driver
I have sent the svg of x01c using svn 8892 to the scribus bug list to see if they could help in getting scribus to import it correctly. The response was swift, and that it opens up nearly ok in scribus 1.3.3.12 (I was running 1.3.3.4), which is nearly the last in the stable 1.3.3 chain, and looks perfect in 1.3.5svn (I sent them screenshots of inkscape and firefox). There are some small text placement issues in 1.3.3.12, and the graph marker glyphs don't come out correctly. I can't build the 1.3.5svn of plplot without updating a lot of other things on my system (and the binary rpm I found on the opensuse site installs ok but is missing dependencies to run), so I can't report on how perfect it is, but since 1.3.3.12 does a fairly decent job and the scribus people report a lot of work on the svg import in the interim, I'd guess that it's very good. Perhaps someone from the plplot list with a newer version of a linux distribution can get 1.3.5svn to run. The windows version of 1.3.5svn does indeed to a pretty good job (and spells shalom right to left as it should), but displaces graph markers slightly (and perhaps all text); it also uses a different font and fails to show superscripts raised and shrunk. I've reported this back to them for further comments. Anyway, generically this is good news and adds scribus to inkscape as an svg editor for plplot touch-ups... Steve On Wed, 2008-10-15 at 15:42 +0100, Steve Schwartz wrote: Hi Alan, On Tue, 2008-10-14 at 09:41 -0700, Alan W. Irwin wrote: However, if you install librsvg and can reproduce the identity -list format result above (i.e., your distribution's ImageMagick build can take advantage of librsvg if it is installed), I think you will see reasonably good display results (positions typically within half a character) like I do. It turns out I do have librsvg installed as part of my distribution (OpenSuse 10.2), but I can't/don't know how to tell my ImageMagick to find it. Maybe there's a way to drop/link it into the ImageMagick coders set of libs and get it found at launch time, but ... In the process, of course, I discovered that part of librsvg includes executables rsvg-view and rsvg-convert, which as you might expect work fine. Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-15 10:13+0100 Andrew Ross wrote: Alan, I've tested the latest svg support on by Ubuntu systems and the report is firefox 3.0.3 - works fine now. Excellent! display (imagemagick 6.3.7) - nearly ok with RSVG driver. alignment is very slightly too far to the right and touches axis. Yes, that is what I see also (the up to half-character shifts I referred to in my report) for my imagemagick 7:6.3.7.9.dfsg1-2+b2 from Debian testing. It is a big improvement over before because of the white space issues I fixed in svg.c, but I am virtually positive the remaining much smaller text shifting issues are due to librsvg. The neat thing with SVG is you can actually look at the XML code and exactly interpret the results for yourself (at least for simple examples). Thus, I am currently preparing a simple example that everybody on the librsvg development team should be able to understand which shows this remaining displacement issue for librsvg but not for other viewers. It might be something as simple as librsvg not counting all the glyphs properly when they are interpreting text-anchor=end (right justification), but we will see. I am going to push this bug report, because a fix to librsvg will propagate to a number of applications. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Alan, I've tested the latest svg support on by Ubuntu systems and the report is firefox 3.0.3 - works fine now. display (imagemagick 6.3.7) - nearly ok with RSVG driver. alignment is very slightly too far to the right and touches axis. With internal SVG driver label alignment and circle symbols are completely wrong. konqueror 3.5.9 (also svgdisplay, ksvg ) - alignment is ok. Points still appear as ? gimp 2.4.5 - like display, the alignment is very slightly too far to the right so labels just touch axis. inkscape 0.46 - works fine now. So this is a vast improvement. In particular the working support for firefox 3 is very pleasing. Display and gimp (both using rsvg) now look much closer to what is expected. They are now useable at least. With inkscape we have a working svg editor as well. So far I've only closely checked example 1. Will work through other examples as well to look for any other issues. Andrew - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On Oct 11, 2008, at 8:14 PM, Alan W. Irwin wrote: There is nothing like preparing a bug report to make you examine your assumptions. My assumptions turned out to be wrong about our -dev svg results, but that is fine because it means I am making some progress. I was in the process of preparing a simple test case for a librsvg bug report (which I fortunately didn't send), when I discovered that - dev svg had at least two text position bugs. The first bug I discovered today was the code incorrectly wrote indentation white space and line end characters (used for human-readability formatting of the xml file but _not_ part of the text itself) between the text and /text tags. Some viewers (konqueror, firefox 2) incorrectly ignored those characters, but others (display and probably firefox 3) correctly rendered them. So the result was standard's compliant but still far from what was intended for the text to be displayed. I'm glad to hear that you figured this out. Is this somewhere in the SVG standard? I was looking at: http://www.w3.org/TR/SVG11/ text.html#TextElement, Example text01, from which I concluded that whitespace and line end characters are ignored. This example has whitespace and line end characters both before and after the text! -Hazen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-12 12:05-0400 Hazen Babcock wrote: On Oct 11, 2008, at 8:14 PM, Alan W. Irwin wrote: [...]The first bug I discovered today was the code incorrectly wrote indentation white space and line end characters (used for human-readability formatting of the xml file but _not_ part of the text itself) between the text and /text tags. Some viewers (konqueror, firefox 2) incorrectly ignored those characters, but others (display and probably firefox 3) correctly rendered them. So the result was standard's compliant but still far from what was intended for the text to be displayed. I'm glad to hear that you figured this out. Is this somewhere in the SVG standard? I was looking at: http://www.w3.org/TR/SVG11/text.html#TextElement, Example text01, from which I concluded that whitespace and line end characters are ignored. This example has whitespace and line end characters both before and after the text! My first clue was when I tried hand-editing the simple test.svg example that I had created with -dev svg. Any reindentation changed the display positions of the text rendered by display! Then I recalled that white-space and line-endings are not ignored within text elements for other xml-based standards I am familiar with such as DocBook and Atom. In fact xslt (the xml to xml transformation specification) has a variety of methods to help you deal with whitespace issues within text elements. So I removed the extraneous white space and line endings (first by hand editing, and then by changing svg.c), and all of a sudden display starting acting a lot more reliably with regard to text positions. I agree the w3c example you mention implies extraneous whitespace and line endings will be ignored within text elements for SVG, but (a) the example might not actually be consistent with the formal standard (which I have not read) or (b) it's possible this is an ambiguity in the formal SVG standard that different applications deal with in different ways. Anyhow, I have chosen to do the safe thing which is to remove the extraneous whitespace and line endings put in by svg.c since it is definitely not part of the text to be plotted. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
There is nothing like preparing a bug report to make you examine your assumptions. My assumptions turned out to be wrong about our -dev svg results, but that is fine because it means I am making some progress. I was in the process of preparing a simple test case for a librsvg bug report (which I fortunately didn't send), when I discovered that -dev svg had at least two text position bugs. The first bug I discovered today was the code incorrectly wrote indentation white space and line end characters (used for human-readability formatting of the xml file but _not_ part of the text itself) between the text and /text tags. Some viewers (konqueror, firefox 2) incorrectly ignored those characters, but others (display and probably firefox 3) correctly rendered them. So the result was standard's compliant but still far from what was intended for the text to be displayed. I have now (revision 8884) removed those extra human-readability formatting characters, and I now get much more consistent text-positioning results with the display programme. However, there is at least one more text-positioning issue which Andrew pointed out previously, but which I missed until now. On 2008-10-07 07:57+0100 Andrew Ross wrote: Some testing with hand-editing the source revealed (not surprisingly) that it is the text-anchor tag that is not being properly used. Try changing middle to start or end and you get some odd results - it looks like the length of the text string used to calculate the position is far too long. The fact that all editors have a similar bug I find disturbing. I wonder if it is related to the transformation matrices? The problem is that the PLplot string justification parameter (which continuously ranges from 0. to 1.) is being interpreted by svg.c as either start (for args-just 0.33), end (for args-just 0.66), or middle (for the the remaining args-just values). From the variety of anchor-tags in results it appears that args-just is used a lot with a variety of different values internally in PLplot for text positioning. However, according to the SVG standard only those three values are allowed for text-anchor. Therefore, the current svg.c approach must be considerably modified to get accurate text positioning corresponding to args-just. What I propose to do is count the number of unicode characters to be rendered (ignoring FCI's) multiply by some factor times the character height, and shift the origin of the string appropriately to account for the PLplot string justification parameter's difference from 0. This approach should only work for simple text layout languages, but then any args-just value other than 0. for CTL languages doesn't make much sense. In sum, I feel I am making excellent progress on understanding the -dev svg text positioning problems that so many people here have encountered. I have fixed one (bad) text-positioning bug as of revision 8884, and I have a plan to deal with the remaining one that I have found. I have some hope that once that remaining bug is fixed we'll have a complete cure for the text positioning problems, but we'll see. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Steve Schwartz wrote: Dear All, For your amusement, I attach a zipped archive with ps and svg files that were created by the plplot Qt driver we are working on. Qt has in-built routines to draw to a range of file formats (including I think png, tiff, jpeg plus ps and svg). The ps files look and print ok for me (except the lines are somewhat faint, which is not obviously just the thickness). The svg throws a few errors from svg-validator, but it looks ok in firefox, konqueror, eye-of-gnome, and can be opened and manipulated by inkscape, karbon14, and scribus (though the last warns that it hasn't implemented all the svg features present). Hi Steve, both look fine, indeed very nice. Can you indicate the difference with the ordinary ps driver? (Or would that give a completely different file?) Regards, Arjen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Arjen, On Tue, 2008-10-07 at 14:54 +0200, Arjen Markus wrote: Can you indicate the difference with the ordinary ps driver? (Or would that give a completely different file?) For sure it would give a completely different file, just as the pscairo and ps drivers within plplot give very different files. Interestingly (if you get excited about such things), the Qt ps file advertises itself as PS-Adope-1.0, that is, not 2.0 or 3.0, and not as an eps - though it does give a bounding box. When we eventually deliver a self-contained Qt driver, you can all run the various plplot examples and compare detailed performance. We're also experimenting with the Qt print dialog, that will redraw the plot directly to a printer rather force the user to save the file somewhere. We do this from a Qt menu attached to the plot canvas on the screen, but I think it should also be possible to drive it directly from the code to the file for batch work. Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-05 22:09-0400 Hazen Babcock wrote: On Oct 3, 2008, at 11:28 PM, Hazen Babcock wrote: On Sep 30, 2008, at 1:39 AM, Alan W. Irwin wrote: (*) Examples 9 and 21: clipping not implemented yet as illustrated by the first page of these examples. I got this to work, but it takes Firefox about 10x longer to render example 9. Thoughts? I'll check it in for now, but we may want to make it optional as we did for the cairo driver. I made text clipping optional as it was really slowing things down for me, you have to turn it on with text_clipping=1. If people prefer we can have the default be on rather than off. I prefer having the best result as default so I have made the change (revision 8859). Interestingly, at least for my firefox version (iceweasel-2.0.0.14-2 from Debian testing) and also display I don't notice any slowdown so efficient SVG clipping must be implemented in both cases. So it appears in this case and also many others we are up against svg viewer software with quite a large range of quality. Hopefully, the situation will rapidly improve as more and more free software graphical applications like ours develop svg generation capabilities, and the developers of such projects start filing bug reports for all other svg-capable free software which has issues dealing properly with our generated results. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Steve Schwartz wrote: Also, I'm still having difficulty printing a postscript plot on a page; it looks fine in ghostscript (with the view set to A4 or Letter paper), but prints to a ps printer blown up by a factor ~4.8. Passing through eps2eps, epstopdf, or any other filter generates a file that prints fine on a page, but I'd be interested in how others print plplot postscript plots. Hi Steve, I have never had much problems with the PostScript output (using the ps device driver), but I use the PostScript filter on our system printers directly. I have had issues with margins, but that is a general problem with printers. Regards, Arjen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-05 22:36-0400 Hazen Babcock wrote: On Oct 4, 2008, at 10:18 PM, Alan W. Irwin wrote: These three issues will not affect my on-going svg PLplot logo work, but it is obviously important to solve them to make -dev svg a complete and outstanding device driver. (1) Subscripts were always being misinterpreted as superscripts, but that was just a sign problem and this should be fixed now. (2) The -ori option, or more correctly pls-diorot, was being ignored by the text rendering subroutine and this should also be fixed. (3) The question is, should cross-hatching be implemented? It looks to me like it has something to do with fill patterns. The relevant flag is pls-dev_fill1. Thanks, Hazen, for drawing my attention to pls-dev_fill1 (which I believe is properly documented in include/plstrm.h). I also read through the core code to confirm that documentation. The question for both fill0 and fill1 is does the driver have the unique native ability to do solid/pattern fills or do you fall back to the PLplot core software to emulate those? The core emulation of solid fills looks pretty bad so it is fortunate that most drivers have that native ability, but the core emulation of pattern fills looks good so it is no problem that most drivers do not have this special capability. I have set pls-dev_fill1 = 0 as a result of these considerations, and as expected, the cross-hatched result automatically generated by the PLplot core looks fine for example 15 now. So your two changes above, this last pls-dev_fill1 change, and also my change to default text clipping means we have an svg device driver now that produces results for all our standard examples that renders with extremely high quality for the right svg viewer (firefox in my case). Also, spot checks of the results indicate they validate at http://validator.w3.org which is an important consideration when reporting issues for our svg results with other software. Many thanks for having the vision and and energy to put this extremely useful device driver together in the first place. Thanks also for doing such a great job of fixing the subset of bugs revealed by the standard examples that I could not handle myself. AFAIK, there is one obscure issue that I noticed by chance that is still left to fix. If you change example 10 to double the character size plschr(0., 2.) then the ends of the string are clipped correctly at the borders of the inner box as expected. However, if you rotate coordinates with the -ori option, the text clipping box does not rotate and clips the rotated enlarged string in the wrong place. (You can also [barely] see the effects of this bug if you do not bother with doubling the text size which is the environment where I spotted it in the first place. But doubling the text size makes the bug completely obvious.) I fiddled with the order of the clipping commands relative to the rotation commands within the resulting svg file, but that seemed to remove all text so I must have been doing something that was not quite correct. If you know a quick fix for this one, that would be great just to get this last known -dev svg issue out of our hair, but I would assign this bug a low priority and put off the fix if you estimate it is going to take a substantial amount of your time to fix. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Hi Arjen, On Mon, 2008-10-06 at 12:51 +0200, Arjen Markus wrote: I have expressed myself somewhat inaccurately: the command by which I send the PostScript files to the printer is simply lp. The printer driver that then gets invoked will do all manner of things to get the file printed, but I do not know what steps are involved - nothing that I need to worry about. Yes, that's what I've tried, to an HP laserjet 2100 and a xerox workcenter. I use CUPS and the printer uses the recommended driver (the HP2100 postscript driver). I've also tried with a generic ps driver - same results. And I've tried it on another linux box (running Debian instead of my OpenSuse). All with the same result. It does print ok from gview on a windows pc (using both the GDI printer specification and postscript). I attach the file (from x01) in case you want to try for yourself. Regards, Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ attachment: x01c_ps.eps- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Steve Schwartz wrote: Hi Arjen, My observation is that one ought to be able to send the postscript file directly to a postscript printer (I've tried both HP and Xerox printers). Passing it through a filter (eps2eps, or whatever - most/all of which amount to passing it through ghostscript) risks degrading it through a rendering engine that might, for example, substitute fonts, or draw them rather than embed them. Ultimately it leads to a bit of frustration if used by the innocent user, or sent to someone else who tries to print it and only ends up with the top left portion (despite it looking fine within ghostview) and who might not know other tricks to play. I guess the issue is somewhere in the way the scaling is handled; other drivers (e.g., the pscairo one) and other (e)psf's don't show this problem, so it must be solvable. I originally wondered if it had something to do with the fact that it was an epsf (figure) rather than a ps (page), but again other epsf's print fine natively to a ps printer. Unfortunately, although I speak a couple of languages in addition to English (including C and a bit of French), postscript isn't one of them. Hi Steve, I have expressed myself somewhat inaccurately: the command by which I send the PostScript files to the printer is simply lp. The printer driver that then gets invoked will do all manner of things to get the file printed, but I do not know what steps are involved - nothing that I need to worry about. Now, I do remember that we had difficulties getting the colours completely correct, but that was an issue under Windows, not under Linux (and something quite apart from PLplot, actually: printers use a colour translation table to get the best fit of a colour specified in PS on paper). Regards, Arjen (who speaks a bunch of languages, also including French, but excluding PostScript) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On Mon, 2008-10-06 at 13:48 +0200, Arjen Markus wrote: I do not know if this will be a disappointment for you, but when I printed via the humble lp command on an OCE printer we have here, it comes out just fine. I am not sure about the margins (some of my colleagues are rather keen on getting the fine details right), but it is a very presentable picture. This neither disappoints nor surprises very much, though it does frustrate. Now, what does that tell us about the nature of the problem? It may be the e part (no fixed bounds, IIUIC)... I wondered that, though running it through eps2eps leaves it an eps file, but that one behaves for me. And it should have some idea about scale, size, resolution, ... and the bounding box at the beginning gives the origin relative to something. [I might have expected it not necessarily to have the right origin - and have encountered similar problems in the past, but I would expect a ps or eps to know what an inch was.] Thanks for retaining interest this long... :-) Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Steve Schwartz wrote: Hi Arjen, On Mon, 2008-10-06 at 12:51 +0200, Arjen Markus wrote: I have expressed myself somewhat inaccurately: the command by which I send the PostScript files to the printer is simply lp. The printer driver that then gets invoked will do all manner of things to get the file printed, but I do not know what steps are involved - nothing that I need to worry about. Yes, that's what I've tried, to an HP laserjet 2100 and a xerox workcenter. I use CUPS and the printer uses the recommended driver (the HP2100 postscript driver). I've also tried with a generic ps driver - same results. And I've tried it on another linux box (running Debian instead of my OpenSuse). All with the same result. It does print ok from gview on a windows pc (using both the GDI printer specification and postscript). I attach the file (from x01) in case you want to try for yourself. Hi Steve, I do not know if this will be a disappointment for you, but when I printed via the humble lp command on an OCE printer we have here, it comes out just fine. I am not sure about the margins (some of my colleagues are rather keen on getting the fine details right), but it is a very presentable picture. Now, what does that tell us about the nature of the problem? It may be the e part (no fixed bounds, IIUIC)... Regards, Arjen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Steve Schwartz wrote: On Mon, 2008-10-06 at 13:48 +0200, Arjen Markus wrote: I do not know if this will be a disappointment for you, but when I printed via the humble lp command on an OCE printer we have here, it comes out just fine. I am not sure about the margins (some of my colleagues are rather keen on getting the fine details right), but it is a very presentable picture. This neither disappoints nor surprises very much, though it does frustrate. Now, what does that tell us about the nature of the problem? It may be the e part (no fixed bounds, IIUIC)... I wondered that, though running it through eps2eps leaves it an eps file, but that one behaves for me. And it should have some idea about scale, size, resolution, ... and the bounding box at the beginning gives the origin relative to something. [I might have expected it not necessarily to have the right origin - and have encountered similar problems in the past, but I would expect a ps or eps to know what an inch was.] Thanks for retaining interest this long... NP - I have been wandering around in this particular territory long enough to know the frustration it brings. But you mentioning inches ... Could that be the cause? PS coordinates are usually in points - 1/72th of an inch. I am a firm believer of the SI units, but could a mistake of cm instead of inches or the other way around cause the unfortunate scaling? Regards, Arjen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-06 13:24+0100 Steve Schwartz wrote: On Mon, 2008-10-06 at 13:48 +0200, Arjen Markus wrote: I do not know if this will be a disappointment for you, but when I printed via the humble lp command on an OCE printer we have here, it comes out just fine. I am not sure about the margins (some of my colleagues are rather keen on getting the fine details right), but it is a very presentable picture. This neither disappoints nor surprises very much, though it does frustrate. Now, what does that tell us about the nature of the problem? It may be the e part (no fixed bounds, IIUIC)... I wondered that, though running it through eps2eps leaves it an eps file, but that one behaves for me. And it should have some idea about scale, size, resolution, ... and the bounding box at the beginning gives the origin relative to something. [I might have expected it not necessarily to have the right origin - and have encountered similar problems in the past, but I would expect a ps or eps to know what an inch was.] Thanks for retaining interest this long... Actually, it is an interesting thread since EPS is so important for embedding PostScript inside other documents. Therefore, I decided to compare psc results with pscairo results (even though I know little of the PostScript language). Here is what I could glean from the comparison. * Different identifications. psc:%!PS-Adobe-2.0 EPSF-2.0 pscairo: %!PS-Adobe-3.0 IOW, psc is specifically identifying itself as encapsulated postscript while pscairo is not. How does the result print if you edit the psc file to remove EPSF-2.0 from the identification? My understanding is that EPS is just a collection of constraints on a valid PostScript document. So if the print result is suddenly well-behaved, that probably means your printer software finds something about the file that it will not accept or misinterprets under the EPS constraints, but which it interprets correctly as PostScript. OTOH if your result is still the same, that probably means there is a general PostScript command buried in the file which your printer is ignoring or misinterpreting. Another experiment I would try is to append EPSF-3.0 to the pscairo identification to see how your printer responds. Even though pscairo is not specifically identified as EPS, it does have a bounding box (which AFAIK is the principal EPS constraint) so it is likely to be valid EPS, and it would be interesting to see if your printer software agreed with that assessment. I hasten to add we would not want to remove the EPS identification for our psc results since I actually think they do follow the EPS rules, but the above experiments might help us figure out what the problem is. * Different methods of specifying the bounding boxes. Note psc has an accurate bounding box while a pscairo deficiency is the bounding box is a little larger than actually required. psc: %%BoundingBox: 44 44 580 738 pscairo: %%BoundingBox: 0 0 540 720 So far so good with psc. In fact, I think one overall bounding box specification (like psc does it) is sufficient according to the EPS standard, but I notice that pscairo repeats the bounding box information for each page, e.g., with %%Page: 1 1 %%BeginPageSetup %%PageBoundingBox: 0 0 540 720 %%EndPageSetup The corresponding psc command is just %%Page: 1 1 Perhaps your printer software needs these extra commands to set up the individual page (even though those commands appear to be redundant for Arjen's printer)? Anyhow, try adding those commands to your psc file (with the exact bounding box values as taken from the psc file header) right after the Page command to see how the printer responds. If that is all that is necessary to satisfy your printer it should be possible to make the relevant changes in ps.c (and also psttf.c which pretty much follows the PostScript style of ps.c). Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Just to add my 2p in. Following all tested on Ubuntu Hardy with rev 8859. Firefox 3.0.3 - Alignment on labels is way off with lettering shifted to the left. Labels are clipped. Konqueror 3.5.9 - Alignment on labels is ok, but points appear as ?. Display (imagemagick 6.3.7) - Alignment on labels is too far to the left, but less so than with firefox. Labels are not clipped as a result. Gimp 2.4.5 - Alignment on labels is too far to the left (comparable to display). Inkscape 0.46 - Alignment on labels is too far to the left (nearly the same as with firefox, but not quite.) As far as I can tell display and gimp both use the buggy librsvg. Firefox uses native svg rendering (hence the slightly different alignment). Konqueror uses the ksvg plugin. Although inkscape links with libMagick, it uses it's own svg engine. N.B. The version of the gecko layout engine in firefox 3.0 implements quite a bit more of the svg 1.1 spec. It may be that this is where the observed differences between firefox versions lie. The conclusion seems to be that 3 out of the 4 svg engines I tested get the label alignment too far to the left, although by varying amounts. Only ksvg gets it right, although it has other problems with symbols. Andrew On Sun, Oct 05, 2008 at 10:35:48PM +0100, Steve Schwartz wrote: Alan, On Sun, 2008-10-05 at 11:19 -0700, Alan W. Irwin wrote: I suggest you try display on example 1 svg results, Actually, display (imagemagick v6.3) is worse - lettering shifted far to the right and plot symbols absent (see attached screenshot) My svg passes the W3C upload test. Which PostScript devices have you tested? The choices are ps, psttf, and pscairo. I haven't built the psttf driver (I think my system is missing something it needs). I've been using the generic ps one. The pscairo one actually works as I had expected it to. But for the software we ship I'd like to stick to a standalone generic ps driver. (and likewise for the svg one) Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Hi Andrew: Thanks for your report on the (sad) state of affairs for the svg viewers available to you. On 2008-10-06 22:38+0100 Andrew Ross wrote: N.B. The version of the gecko layout engine in firefox 3.0 implements quite a bit more of the svg 1.1 spec. It may be that this is where the observed differences between firefox versions lie. You confirm what Hazen found for firefox 3 on OS X. I agree it is possible that later firefox versions do better at implementing the svg 1.1 spec, but that would mean that there is a problem with the w3c validator that is telling us that our -dev svg results are within the 1.1 spec. I hope that w3c has gotten their validator right since so many people depend upon it! My own alternative hypothesis is firefox 3 has expanded their svg support like you say beyond what was provided by the firefox 2 version which renders our svg results so nicely for me. However, I assume that reworking must have introduced bugs in the part of the spec that they supported properly before and which is used by our -dev svg results. Interactions with the firefox developers via bug reports can help decide between the hypotheses. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
I've been experimenting with the svg driver (using svn 8854). Here are some observations: inkscape will now open the svg generated from x01c, though all the labels and text show up displaced to the left. But it renders fine in firefox, konqueror, and virtually everything I've tried scribus (v 1.3.3.4) will also open up, but makes a mess of it. This is a pity, because I'm a big fan of this software, and I may send the svg to them to see if they have any comments or improvements. karbon14 will open it up and it looks pretty good, EXCEPT that the superscripted text is not superscripted nor sized smaller. But it is less temperamental than inkscape I've looked at a few other svg editors (sketsa, sodipodi, ...) but none look to be advancing to the point where they are practical. Any other suggestions would be welcome. Also, I'm still having difficulty printing a postscript plot on a page; it looks fine in ghostscript (with the view set to A4 or Letter paper), but prints to a ps printer blown up by a factor ~4.8. Passing through eps2eps, epstopdf, or any other filter generates a file that prints fine on a page, but I'd be interested in how others print plplot postscript plots. Regards, Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On Sun, 2008-10-05 at 13:14 +0100, Steve Schwartz wrote: inkscape will now open the svg generated from x01c, though all the labels and text show up displaced to the left. And the plot symbols are also shifted! Actually, the plot symbols don't show up in Firefox 2.0, and show up as ? in konqueror. The Cairo svg driver generates svgs that are MUCH easier to manipulate in inkscape - I guess this has to do with the structure and hierarchy of the objects and drawing elements in the xml code. But the text and graph symbols are corrupted and/or missing. karbon14 likewise opens these without any text or markers. Scribus recognises that it doesn't support all the svg features in the cairo svgs and barely shows anything. Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Hi Steve: Thanks for your tests of revision 8854. On 2008-10-05 13:14+0100 Steve Schwartz wrote: I've been experimenting with the svg driver (using svn 8854). Here are some observations: inkscape will now open the svg generated from x01c, though all the labels and text show up displaced to the left. But it renders fine in firefox, konqueror, and virtually everything I've tried scribus (v 1.3.3.4) will also open up, but makes a mess of it. This is a pity, because I'm a big fan of this software, and I may send the svg to them to see if they have any comments or improvements. karbon14 will open it up and it looks pretty good, EXCEPT that the superscripted text is not superscripted nor sized smaller. But it is less temperamental than inkscape I've looked at a few other svg editors (sketsa, sodipodi, ...) but none look to be advancing to the point where they are practical. Any other suggestions would be welcome. I think you have probably looked at everything suggested in http://www.linux.com/feature/148630 and in the comments to that article, but you should double-check that. One of the observations of that review (that the various Linux svg editors didn't even understand each other's brand of svg) means one of two things. (1) Some of them are outputting bad svg. I hope that is not the case since that is so easy to check at http://validator.w3.org. BTW, when you send in bug reports to the svg editor developers, I suggest that you check the PLplot results against http://validator.w3.org using their file upload mechanism and mention that in your bug report. I think that will get a lot more attention for your bug report than saying something equivalent to your application cannot interpret PLplot svg output. (2) The various svg editors have only implemented a subset (the same subset they output) of the full svg standard for input. IMO, this latter explanation is more likely from your above observations with how the various editors mess up the svg standards-compliant example 1 result. One ray of hope in this mess is the inkscape problems you describe sound awful familiar. That is how all librsvg-based svg viewers (such as the display application from ImageMagick) qualitatively mess up as well. I suggest you try display on example 1 svg results, and if it is giving you the identical rendering errors as inkscape, then it probably means inkscape is also using librsvg which in turn means we can potentially knock off a lot of these application issues by bringing the problem to the attention of the librsvg developers. Also, I should mention that whenever I tried display on any of our examples, the only rendering issue that showed up was the left-displacement one that is illustrated by the example 1 results. So we are probably only dealing with one bug in librsvg as opposed to many. The other ray of hope is Linux application developers are just now becoming svg aware after years of neglecting the standard. (PLplot is a case in point, but KDE is an even larger one where they have migrated all their desktop icons to svg recently [KDE4] for the first time.) The existence of many additional kinds of svg standards-compliant output from ever-increasing varieties of Linux applications is bound to put pressure on svg editors to get their act together to implement the full svg standard for input. What to do in the meanwhile? (1) Identify the svg editor you like for other reasons (from above, it sounds like that would be scribus) and focus on that one. Insist through your bug reports that they fix their import module sufficiently so that at least the standards-compliant figure 1 svg result (and eventually all the svg results from the PLplot standard examples) are imported and interpreted exactly as they are rendered by firefox. (2) I was going to suggest you try -dev svgcairo, but it appears the various editors have a different set of difficulties with that device according to your later e-mail which I will answer separately. Also, I'm still having difficulty printing a postscript plot on a page; it looks fine in ghostscript (with the view set to A4 or Letter paper), but prints to a ps printer blown up by a factor ~4.8. Passing through eps2eps, epstopdf, or any other filter generates a file that prints fine on a page, but I'd be interested in how others print plplot postscript plots. I work from a home office with no printer so I haven't tested any of our PostScript devices in a long time by actually attempting to print the result. Which PostScript devices have you tested? The choices are ps, psttf, and pscairo. Alan __ Alan W. Irwin 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 libLASi project
Re: [Plplot-devel] Status of the svg device driver
On 2008-09-30 10:07+0100 Steve Schwartz wrote: Taking this as a hint, I can edit the -dev svg to get it to open in inkscape and konqueror by deleting the leading document tag (and it's close at the end of the file). Hi Steve: I fixed that bug last week when I started my svg effort. So I am very interested in your experiments, but please use the latest version of PLplot from svn trunk to access all the svg bug fixes I have been making. I know you have used svn trunk before so I suspect that you just forgot to do an svn update or else you did not rebuild starting from an empty build tree. That update/rebuild may cure most of the problems you have encountered, but I am very interested in any that persist after that update for example 1. For example, that update will not cure the ImageMagick/librsvg X offset issues I commented on already. I am virtually positive that is a librsvg bug so I plan to make a really simple case, validate it at http://validator.w3.org (to make absolutely sure it is compliant with the svg standard), and send in a bug report to librsvg with screenshots of what you get with librsvg versus other standards compliant viewers. Hopefully, that will get some action. I should mention that figure 1 looks perfect here for firefox. For konqueror everything is fine for Figure 1 except for the circles used to mark points which it replaces by question marks because its ability to find non-standard glyphs amongst the system fonts is so poor. As I mentioned, I will be sending in a konqueror bug report on that issue. You mentioned you liked svg. I like it too because it produces such good-looking results (for good viewers like firefox, konqueror, and hopefully for imagemagic/librsvg soon), and it has the capability of being scaled without getting the artifacts associated with bitmap scaling. On top of that its xml output is really straightforward to understand; that was a big help in sorting out a number of the svg issues that I mentioned, and I am going to rely on being able to humanly parse the results to help me sort out the additional minor xml tag issues I will be working on today (for some figures, but not figure 1.) I have just checked specifically that figure 1 validates so every viewer that is svg 1.1 standards compliant and which has proper access to fonts should render it the same way, i.e., like firefox. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-09-29 22:39-0700 Alan W. Irwin wrote: In general, our svg results look really good with [Debian testing] firefox, and I believe -dev svg produces everything I need to generate a good-looking SVG PLplot logo using PLplot itself, but there are still some outstanding issues that I noticed when looking at the complete set of examples. I mark the ones listed below that I am investigating further using (AWI). The one that is caused by an issue in another library is marked by (Nobody). Finally, the ones marked (*) are too difficult for me so they are up for grabs for some eager volunteer to show off his device driver skills. :-) Well that volunteer has stepped forward for quite a few of the issues. Thanks, Hazen. I have also made some progress myself. However, there are still some issues left. I didn't check all the examples this time, but to start I did look at examples 1 and 2, and the vertical spacing still looks good after our recent changes (Revision 8853). (*) Example 3: the text does not rotate accurately around this polar plot. For example, the center of the text rotation seems offset from the center of the plot. The first page of Example 28 also appears to show this problem. I assume these issues are caused by some text offset issue that has not been taken care of properly in the svg device driver when doing rotational transformations of text. (*) The example 3 issue and example 28 page 1 issues are fixed thanks to Hazen's changes. However, a remaining issue (probably completed unrelated) seen for example 28 pages 2 and 3 is that subscripts are being interpreted as superscripts (!). (AWI) Example 6: some of the horizontal rules are missing. Strangely, the seemingly equivalent horizontal rules in Example 7 are fine. (AWI) Not fixed yet. (*) Examples 9 and 21: clipping not implemented yet as illustrated by the first page of these examples. Fixed by Hazen. (*) Example 10 (and presumably others) Text does not rotate at all with the -ori option. (You have to run the installed examples to check out the results from that option.) Again, this is some sort of rotation/transformation issue, but it looks like at least in this case the rotational information doesn't get to the text at all. This may well be related to the example 3 issue above. (*) Not fixed yet. (*) Example 15: cross-hatching not implemented yet as illustrated by both pages. (*) Not fixed yet. (AWI) Example 20: empty pages 2,5,7,and 10 have an xml screwup that is probably related to the familying logic. The empty pages in Example 20 were caused by extra pladv(0) calls. I got rid of those extra pladv(0) calls to get rid of the empty pages associated with that example. However, generating empty pages should be a valid under PLplot so I started working on an equivalent simple example consisting of repeat pladv(0) calls. For that simple test, I solved the issue by my recent plGetFam change that restores the initial value (AT_BOP) of pls-page_status when plGetFam is called from the driver's plP_bop-* routine after the plP_init call. plP_init changes the page_status to AT_EOP which screws up the page logic for empty pages for the familied case without the restoration of the initial value of pls-page_status. (AWI) Example 21: first four figures (out of 6 on the second page) display and then get blanked. The last two figures on the page display and do not get blanked. The third page of this example (and also example 1) seem to have a similar setup (multiple subpages per page), but no such issues. (AWI) not fixed yet. (AWI) Example 23: pages 12-16 have an xml screwup (at least /g and /svg are missing at end of file) that is probably related to the familying logic. Fixed by my recent plGetFam change, see above. The issue here was not empty pages, but instead pages consisting entirely of text. Such pages currently do not change page_status (which is why my plGetFam empty page fix also solved this issue). However, just on general principles, I think such pages should change page_status so that issue is being discussed in the separate README.pages list thread. In sum, we have made some good svg device-driver progress as of revision 8853, but I still have two issues I still need to look at (ex. 6 missing lines, and ex. 21, page 2 where 4 of the 6 subplots disappear), and there are three others (ex. 28 subscript/superscript, ex. 10 text rotation, and ex. 15 cross-hatching) that are probably too difficult for me so I hope someone else will take them up. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-04 16:38-0700 Alan W. Irwin wrote: In sum, we have made some good svg device-driver progress as of revision 8853, but I still have two issues I still need to look at (ex. 6 missing lines[...] This was an easy one. It was caused by example 6 drawing exactly to the maximum possible X physical device coordinate, and driver scaling causing internal PLplot X coordinate overflow for just that case. (This bug was also recently introduced into gd.c and cairo.c by some scaling changes I made for those device drivers.) The solution is to scale by PIXELS_X-1 rather than PIXELS_X (which has the value 32768 which will overflow signed short integers). Now fixed for gd, cairo, svg (and also wingcc and cgm but not tested for those device drivers). The other devices that use PIXELS_X (e.g., xwin) appear to have alternative logic for solving this issue already. I am still working on one svg issue (4 out of 6 missing subpage plots for page 2 of example 21). Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-04 18:19-0700 Alan W. Irwin wrote: I am still working on one svg issue (4 out of 6 missing subpage plots for page 2 of example 21). Two for the price of one! Solving the coordinate overflow issue solved this one as well. I wish they were all this easy. So I am done with the svg issues I volunteered for (as of revision 8854). The remaing three issues which I am aware of (and which are probably too tough for me) are subscripts being misinterpreted as superscripts in example 28 (pages 2 and 3), rotation of text not working for the -ori option for example 10 (and presumably all other examples), and hatching not implemented yet (see example 15). These three issues will not affect my on-going svg PLplot logo work, but it is obviously important to solve them to make -dev svg a complete and outstanding device driver. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-10-03 21:57-0400 Hazen Babcock wrote: Unfortunately I think that we even need to specify which OS and/or which version of Firefox should be used to get good results. I've attached two quite different, at least in terms of text placement, versions of example1, one from debian w/ Firefox 1.5.02 and the other from OS-X w/ Firefox 3.0.3. Was this the x-displacement issue that you were referring to? Almost exactly. In fact, it is so close I am wondering if somehow Firefox 3.0.3 on OS X is also using the buggy librsvg library to render? You have obviously got good results for a very old version of firefox (from Debian oldstable?), and I do as well for the firefox version 2.0.0.14-2 on Debian testing, but I only have the above speculation about what might be going on for OS X, and an extremely recent version of firefox. I hope to get to the bottom of the issue for librsvg which will cover off at least display and rsvg-view. Do you have access to other svg viewers on OS X such as earlier firefox versions? Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Hi Alan, On Tue, 2008-09-30 at 08:03 -0700, Alan W. Irwin wrote: I fixed that bug last week when I started my svg effort. So I am very interested in your experiments, but please use the latest version of PLplot from svn trunk to access all the svg bug fixes I have been making. I know you have used svn trunk before so I suspect that you just forgot to do an svn update or else you did not rebuild starting from an empty build tree. OK, I'll confess that I don't download svn updates on a daily basis - I tend to work on a need to know basis. I'll do so when I next get a chance and then comment on svg issues. We will at some point have an alternative svg route for plplot in that we are finishing a Qt plplot driver. The Qt widgets support output in various formats including svg. I don't know the extent to which that will preserve the nice vector properties that make svg attractive. We've delayed this a bit because the interface for Qt4 is quite different from Qt3 and we are in the process of migrating bits of our code to Qt4 along with numerous other improvements (a major one of which is moving to plplot which is nearly complete). Steve -- +---+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric PhysicsFax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +---+ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
Interestingly, the following article on SVG editors just appeared on linuxtoday.com today. http://www.linux.com/feature/148630 -- Maurice LeBrun - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Status of the svg device driver
On 2008-09-30 23:24-0500 Maurice LeBrun wrote: Interestingly, the following article on SVG editors just appeared on linuxtoday.com today. http://www.linux.com/feature/148630 Yeah, I just finished reading that 5 minutes before I saw your post. There was one negative point in there that I found disturbing; various Linux svg editors apparently don't talk to each other very well via svg. My additional recent experience is the librsvg-based svg viewers such as the ImageMagick display app misinterpret standard svg commands about x positioning of text. (Fortunately, that appears not to be a problem for konqueror and firefox.) Haven't all these svg application developers with svg i/o issues ever heard of following/supporting standards? Of course, our own situation is much simpler because we don't have the input problem where you have to support essentially the whole standard in order to understand everyone else. That simplification allows us to use programming by Hazen to output the SVG file for -dev svg using a tiny subset of the svg-1.1 standard. However, at least I have tested that -dev svg output extensively to make sure the result is compliant with the svg-1.1 validator at http://validator.w3.org. Alan __ Alan W. Irwin 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 libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
