From: Steve S. <s.s...@im...> - 2008-10-06 12:25:05
|
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 Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Arjen M. <arj...@wl...> - 2008-10-06 15:01:53
|
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 |
From: Arjen M. <arj...@wl...> - 2008-10-06 13:03:35
|
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 |
From: Alan W. I. <ir...@be...> - 2008-10-06 18:19:15
|
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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-10-07 13:06:19
Attachments:
demos.zip
|
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). Steve -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Andrew R. <and...@us...> - 2008-10-07 00:11:42
|
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 Physics Fax: +44-(0)20-7594-7772 > The Blackett Laboratory E-mail: s.s...@im... > 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=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Alan W. I. <ir...@be...> - 2008-10-07 03:30:33
|
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 __________________________ |
From: Andrew R. <and...@us...> - 2008-10-07 07:00:36
|
On Mon, Oct 06, 2008 at 08:29:45PM -0700, Alan Irwin wrote: > 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. 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? One option would be to do the alignment by hand to attempt to circumvent this issue. Andrew |
From: Steve S. <s.s...@im...> - 2008-10-07 07:09:41
|
Hi Alan, I've tried all your experiments and they all fail. The pscairo file continues to behave if advertised as an eps, and the psc fails when advertised as a ps. Trying to add more page information doesn't help. None of this surprises me, as I suspect the problem lies in the interpretation of the scaling instructions: /@SetPlot { ho vo translate XScale YScale scale lw setlinewidth } def /XScale {hs 3600 div} def /YScale {vs 2700 div} def and they way this is subsequently interpreted by my printers, but here my hacking and lack of fluency in ps fail me (I've tried to hack the XScale and YScale values and they do shrink/expand the plot on the page, but then, of course, ghostscript gets it wront on the screen. I also tried hacking the psc file to pretend it was EPSF-3.0 Steve On Mon, 2008-10-06 at 11:14 -0700, Alan W. Irwin wrote: > 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 > __________________________ -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Steve S. <s.s...@im...> - 2008-10-07 07:35:30
|
If it helps anyone, commenting out the line XScale YScale scale from the /@SetPlot definition (a) make ghostscript render only the top left portion (exactly the portion I see when I print the original file) and (b) has no effect on the printer output. So it looks like my printer(s) ignore the scaling. Parlez-vous postscript? Steve On Tue, 2008-10-07 at 08:06 +0100, Steve Schwartz wrote: > None of this surprises me, as I suspect the problem lies in the > interpretation of the scaling instructions: > > /@SetPlot > { > ho vo translate > XScale YScale scale > lw setlinewidth > } def > /XScale > {hs 3600 div} def > /YScale > {vs 2700 div} def -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Arjen M. <arj...@wl...> - 2008-10-07 13:04:46
|
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 |
From: Steve S. <s.s...@im...> - 2008-10-07 13:13:26
|
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 Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2008-10-12 00:14:57
|
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 __________________________ |
From: Hazen B. <hba...@ma...> - 2008-10-12 16:09:30
|
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 |
From: Alan W. I. <ir...@be...> - 2008-10-12 17:26:18
|
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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-12 18:15:34
|
On 2008-10-12 10:26-0700 Alan W. Irwin wrote: > I agree the w3c example you mention implies extraneous whitespace and line > endings will be ignored within text elements for SVG [...] Hi Hazen: I have found a good reference on this question. See http://www.w3.org/TR/SVG11/text.html and look for "xml:space". svg.c specifies xml:space "preserve" which is the reason indentation and line endings made a difference with the old code. I think we still want this option (since the user may want some legitimate extra whitespace in his plot labels) so I think the present code (which preserves user white space but makes sure svg.c doesn't add any) is exactly what we want. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2008-10-14 08:34:23
|
On 2008-10-11 17:14-0700 Alan W. Irwin wrote: > 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. OK, I am now finished with this as of revision 8892. To explain how I deal with the last identified issue, notice that the choice of anchor tag was perfect for justifications of 0., 0.5., and 1.0. Thus, I calculated a rough sum of the glyph sizes (this algorithm should only be correct for monospaced fonts), and applied a differential correction proportional to the difference of the justification from the nearest of 0., 0.5, or 1.0. Since these justifications are the ones chosen for all standard examples other than example 3, and the deviation from those justifications is small in that case, the standard examples don't provide much of a test of my differential correction. However, I did check the empirical proportionality constant I use with special examples with fairly long character strings like "HHHHHHH", etc., and also printed out results for sum_glyph_size, and I think the differential correction should be okay. Certainly it makes a nice looking result for example 3. I have only spot checked a few examples other than 3, but what I checked continues to look good for firefox 2 (with glyph lookup problems expecially for the exotic fonts of example 24) and konqueror (with substantially worse glyph lookup problems) so there is essentially no change in those cases except for the improvement to example 3 (the degree labels are not crammed so tightly to the circle anymore). Where the major change is expected is for other viewers and also for svg editors because of the extraneous extra spaces and newline characters that I removed from the <text> tag values produced by svg.c. Andrew, and Steve (and anybody else) could you try your tests again of svg results for revision 8892? I think the positioning results will be a lot better than before but if your applications had trouble with glyph finding before (i.e., text is missing altogether), that issue will remain unchanged. If your tests show good positioning results, then I will ascribe the remaining small positioning issues (up to a half-character width displaced from the correct position) with "display" to librsvg problems, but in any case I hope/believe I am done with my refinements to this 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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-10-14 11:08:59
Attachments:
display.png
|
Alan, OK, I've built 8892 and tested the results from x01c in various editors and viewers. I also tried x24. Here's a synopsis: Viewers - ok including glyph circle as graph marker ======= Firefox (3.0.3) Eye of Gnome Viewers - ok except ? instead of graph marker ======= konqueror gwenview (kde) epiphany (no graph markers at all) Editors ======= inkscape - all ok scribus - still terrible gimp (renders to bitmap, but everything is where it belongs) karbon14 - no graph markers but rest ok display (imagemagick) does a terrible job with this (see attached). There aren't any graph markers and ALL the text is severely displaced to the right. And out of curiosity I tried x24. Inkscape only finds some of the glyphs. Firefox actually finds them all I think (I compared with the cairo x-window driver) but prints two of them backward: top left (hebrew) and 3rd down on the right (that I don't instantly know). I remember enough of my hebrew to recognise the characters making up Shalom (and of course that it is written right to left). But firefox and others write it left to write. Anyway, I think you've solved a large part of the text displacement issues at this level (the graph markers fall on the curves), though clearly not all applications cope equally well with the result. HTH Steve On Tue, 2008-10-14 at 01:31 -0700, Alan W. Irwin wrote: > Andrew, and Steve (and anybody else) could you try your tests again of > svg > results for revision 8892? I think the positioning results will be a > lot > better than before but if your applications had trouble with glyph > finding > before (i.e., text is missing altogether), that issue will remain > unchanged. > > If your tests show good positioning results, then I will ascribe the > remaining small positioning issues (up to a half-character width > displaced > from the correct position) with "display" to librsvg problems, but in > any > case I hope/believe I am done with my refinements to this driver. > -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Space and Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2008-10-14 16:41:51
|
On 2008-10-14 12:06+0100 Steve Schwartz wrote: > Alan, > > OK, I've built 8892 and tested the results from x01c in various editors > and viewers. I also tried x24. Here's a synopsis: > > Viewers - ok including glyph circle as graph marker > ======= > Firefox (3.0.3) > Eye of Gnome > > Viewers - ok except ? instead of graph marker > ======= > konqueror > gwenview (kde) > epiphany (no graph markers at all) > > Editors > ======= > inkscape - all ok > scribus - still terrible > gimp (renders to bitmap, but everything is where it belongs) > karbon14 - no graph markers but rest ok > > display (imagemagick) does a terrible job with this (see attached). > There aren't any graph markers and ALL the text is severely displaced to > the right. > > And out of curiosity I tried x24. Inkscape only finds some of the > glyphs. Firefox actually finds them all I think (I compared with the > cairo x-window driver) but prints two of them backward: top left > (hebrew) and 3rd down on the right (that I don't instantly know). I > remember enough of my hebrew to recognise the characters making up > Shalom (and of course that it is written right to left). But firefox and > others write it left to write. > > Anyway, I think you've solved a large part of the text displacement > issues at this level (the graph markers fall on the curves), though > clearly not all applications cope equally well with the result. > > HTH Hi Steve: That report helps a lot and gives me a big sigh of relief. I was especially delighted to hear that the results for firefox 3 have perfect positioning just like firefox 2. Thanks! I believe I know the reason for your "display" results with terrible text placement. There are actually two independent svg interpreters available with ImageMagick. To see what is available with ImageMagick, try identify -list format |grep -i svg The results here are MSVG* SVG rw+ ImageMagick's own SVG internal renderer SVG* SVG rw+ Scalable Vector Graphics (RSVG 2.22.2) SVGZ* SVG rw+ Compressed Scalable Vector Graphics (RSVG 2.22.2) All my (reasonably good) "display" results were achieved with SVG (which I get by default) rather than MSVG. However, if I force MSVG with, e.g., display MSVG:x01c.svg.01 I get the same terrible position results that you showed in your attachment. I expect you don't have librsvg installed which is why you are getting MSVG results by default from "display". 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. With regard to example 24, firefox 2 here is missing all exotic glyphs so your firefox 3 results are an improvement even though the CTL (Complex Text Layout) language (Arabic, Hebrew, and Hindi) glyphs are not rendered in the correct order. Interestingly, the SVG: display renders everything in that example in the correct order which implies svg.c is not interfering with the downstream application's ability to handle CTL results. However, some of the X offsets are much larger (half the peace word length) then the typical half-character displacements of other examples. I assume librsvg just doesn't know yet how to deal with text-anchor="middle" (i.e., centred justification of words) for CTL scripts. It was good to hear that inkscape import worked fine not only because it gives us all at least one svg editor that we can use with PLplot -dev svg results, but also because it should help you light a fire under scribus to fix up their import ability. Thanks, again, for running all of these tests. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2008-10-15 15:28:28
|
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 Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Steve S. <s.s...@im...> - 2008-10-16 14:26:42
|
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 Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2008-10-16 19:33:16
|
On 2008-10-16 15:28+0100 Steve Schwartz wrote: > 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... Your comments inspired me to try the latest Scribus svn snapshot version which apparently is from about 3 weeks ago. For Debian users here, these are the instructions for building and installing that as a Debian package. Note, you should always use the scribus-ng Debian package name to get the latest ("next-generation") scribus svn snapshots. The scribus Debian package name always refers to the stable 1.3.3.xxx series. N.B. I put an asterisk in front of the steps that must be done as root. All the rest can be done as an ordinary user. *(1) Edit /etc/apt/sources.list deb-src http://debian.scribus.net/debian/ testing main non-free contrib I specified deb-src rather than deb because this site appeared not to have amd64 (my architecture) built. An attempt to run "apt-get update" revealed I had to import the scribus debian signing key. (2) Import the key gpg gpg --search-keys scribus choose the one with EEF818CF to import (3) Export that key to an ascii file gpg --armor --export EEF818CF > scribus.sig *(4) Import that keyfile into the apt infrastructure apt-key add ~irwin/scribus.sig *(5) update local apt files with new repository information. apt-get update (6) Find out what exact versions are accessible apt-cache showsrc scribus-ng *(7) Install all the build dependencies of latest version available apt-get build-dep scribus-ng=1.3.5.dfsg~svn20080921-1 (8) Get, unpack, and build deb packages for scribus-ng N.B. use the apt-src command not apt-get. apt-src build scribus-ng=1.3.5.dfsg~svn20080921-1 *(9) Install the resulting deb dpkg --install scribus-ng_1.3.5.dfsg~svn20080921-1_amd64.deb That's the end of the Debian install instructions. I have never used scribus-ng (or even scribus) before, but the scribus-ng GUI is pretty straightforward. I did run into one import issue; scribus only accepts SVG file names with a ".svg" suffix so I had to rename our various x??c.svg.?? files to something ending in that suffix in order to import them. Once that issue was solved I imported renamed versions of x01c.svg.01, x02c.svg.02, x08c.svg.04, x09c.svg.01, x23c.svg.06, and x24c.svg.01.. In all cases the text placement was absolutely perfect! For example 9, I could expand the result as much as I wanted, and it still looked good (until I magnified it so much that the positioning artifacts caused by PLplot's 16-bit internal storage of positions were beginning to show!) For example 23 all mathematical symbol glyphs seemed to be available. For example 24 all glyphs are available and the glyph rendering order (including the complex Hindi one where one glyph is rendered in different order than the the usual left-to-right order used for the rest of the Hindi glyphs) is perfect! So I am happy with this result. It can now be argued that our svg device produces the best-looking and most accurate results of all our devices _so long as you use software with decent SVG import capability_. BTW, although this snapshot version of scribus-ng imports perfectly, It does not seem quite ready for prime time in other ways. I was happily importing various svg's when at one point the memory use went through the roof, and I had to kill it before I ran into an out-of-memory condition on my computer. I then invoked scribus-ng again and continued to import the same and other files with no further OOM troubles. Hopefully, the scribus team will stabilize this version and release it soon so that everybody can utilize their new high-quality svg import facilities. Until then, apparently you will be stuck with some small positioning issues for the latest version of the current 1.3.3.xxx stable series. 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 __________________________ |
From: Steve S. <s.s...@im...> - 2010-10-05 12:01:18
|
Alan, In looking over legend things, I've discovered that as of 5.9.7 (and probably also 5.9.6 but I only have 5.9.5 built) there have been a few changes to the hershey-unicode mappings that don't work with the qt driver (but are ok with the xcairo one). I presume this is down to my local font holdings. I append below the summary and workaround I sent internally to my team in order to get our software to display the relevant characters. It looks like for some characters you have decided to pick them not from the standard Greek family ( 0x03a,b,c ) but a variant (0x03d,f). I run an OpenSuse 11.1 system. Gucharmap shows both the symbols and alternatives, and the xcairo driver finds them, so I guess they reside somehow on my system but not accessed by my version of qt (4.5.3). I don't know if you want this submitted as a bug, or if your own systems do better. Let me know... Regards, Steve [ snip ...] Some Greek characters have been moved in plplot to what I presume they find more appealing alternatives. The escapes in question include #gU and #gh (capital Upsilon and lower case theta respectively). Additionally there are two more characters, lunate epsilon and a variant of lower case phi, that can be invoked by plsym but don't work for me. This appears to be a shortcoming in qt, as the Cairo drivers can find them. As before, the "fix" involves changing entries in plhershey-unicode.h: Hershey numbers plplot5.9.7 unicode change to this 46, 546 0x03d2 0x03a5 Upsilon 534 0x03d1 0x03b8 theta 98, 684, 2184 0x03f5 0x03b5 epsilon 686, 2186 0x03d5 0x03c6 phi variant -- +-------------------------------------------------------------------+ Professor Steven J Schwartz Phone: +44-(0)20-7594-7660 Head, Space & Atmospheric Physics Fax: +44-(0)20-7594-7772 The Blackett Laboratory E-mail: s.s...@im... Imperial College London Office: Huxley 6M67A London SW7 2AZ, U.K. Web: www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ |
From: Alan W. I. <ir...@be...> - 2010-10-05 18:00:01
|
On 2010-10-05 13:02+0100 Steve Schwartz wrote: > [...]Gucharmap shows both > the symbols and alternatives, and the xcairo driver finds them, so I > guess they reside somehow on my system but not accessed by my version of > qt (4.5.3). I used to encounter this same difficulty (Qt was not as good at finding system fonts as xcairo and gucharmap). I speculate that older versions of Qt used their own library for finding system fonts and not the standard fontconfig library that is used by xcairo and gucharmap or else Qt used fontconfig in a poorly configured way. However, for Qt-4.6.3 (the version that comes with Debian testing) I have not encountered this issue. For example, the Hershey numbers below are all rendered fine with example 7 and -dev qtwidget. > Hershey numbers plplot5.9.7 unicode change to this > 46, 546 0x03d2 0x03a5 Upsilon > 534 0x03d1 0x03b8 theta > 98, 684, 2184 0x03f5 0x03b5 epsilon > 686, 2186 0x03d5 0x03c6 phi variant As you can see from Section 2.28 of our release announcement, later versions of Qt seem to solve a number of issues we see for earlier versions of Qt so the fix for this font-finding issue appears to be just one more fix in the series of Qt improvements that also doesn't seem to have introduced any regressions (at least up to 4.6.3). So TrollTech/Nokia seem to have a pretty good track record for constantly improving Qt4. The Qt download site at http://qt.nokia.com/downloads/ gives you access to the latest Qt version (currently 4.7.0) in binary form. If that version works well for you (i.e., solves the above issue without introducing any regressions), then you might want to recommend it to your QSAS users that don't have access to Qt-4.6.3 or above from their distribution. Alternatively, you could temporarily deploy the above workaround until essentially all distros have updated to 4.6.3 or above. Finally, these issues remind me again that plpoin and plsym access unicode glyphs in an indirect and extremely limited way. Therefore, I have decided it is long past time we introduced a new function plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to the ucs4 index for those drivers which are unicode aware. Such a function would allow users full and direct access to the extremely wide variety of generic sans and serif glyphs that are available on their system for unicode-aware device drivers like qt (with Qt-4.6.3 or later) or cairo. I will try implementing a first cut at plglyph later today. 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 __________________________ |
From: Schwartz, S. J <s.s...@im...> - 2010-10-05 19:29:45
|
Hi Alan Ok as I suspected it is a qt issue and I agree that the qt3 Oct 2010, at 21:01, "dabergsare@comcast. guys mostly make positive improvements - although the migration of our code from Qt3 to Qt4 was far from painless. Since we bundle plplot with our software and deal with a variety of users who won't want to fetch/install alternate qt installations we'll run with my workaroumd for the time being. Thanks for the confirmation that it should work on newer installations - I may check my own qt installation to see if I can configure it to pick up the necessary fonts. It leaves me with a more philosophical and aesthetic question that I pose without malice: Should plplot draw it's Greek theta from a script-like font when all the other Greek symbols (bar uppercase upsilon) are drawn from the default sans serif font? Would it look strange to a Greek person to see a word spelled with this mixture of fonts? I suspect I'm the only one who might have noticed :-) Regards Steve ----------- Steve Schwartz Space and Atmospheric Physics Imperial College London Tel 020 7594 7660 On 5 Oct 2010, at 19:00, "Alan W. Irwin" <ir...@be...> wrote: > On 2010-10-05 13:02+0100 Steve Schwartz wrote: > >> [...]Gucharmap shows both >> the symbols and alternatives, and the xcairo driver finds them, so I >> guess they reside somehow on my system but not accessed by my version of >> qt (4.5.3). > > I used to encounter this same difficulty (Qt was not as good at > finding system fonts as xcairo and gucharmap). I speculate that older > versions of Qt used their own library for finding system fonts and not > the standard fontconfig library that is used by xcairo and gucharmap > or else Qt used fontconfig in a poorly configured way. However, for > Qt-4.6.3 (the version that comes with Debian testing) I have not > encountered this issue. For example, the Hershey numbers below are > all rendered fine with example 7 and -dev qtwidget. > >> Hershey numbers plplot5.9.7 unicode change to this >> 46, 546 0x03d2 0x03a5 Upsilon >> 534 0x03d1 0x03b8 theta >> 98, 684, 2184 0x03f5 0x03b5 epsilon >> 686, 2186 0x03d5 0x03c6 phi variant > > As you can see from Section 2.28 of our release announcement, later > versions of Qt seem to solve a number of issues we see for earlier > versions of Qt so the fix for this font-finding issue appears to be > just one more fix in the series of Qt improvements that also doesn't > seem to have introduced any regressions (at least up to 4.6.3). So > TrollTech/Nokia seem to have a pretty good track record for > constantly improving Qt4. > > The Qt download site at http://qt.nokia.com/downloads/ gives you > access to the latest Qt version (currently 4.7.0) in binary form. If > that version works well for you (i.e., solves the above issue without > introducing any regressions), then you might want to recommend it to > your QSAS users that don't have access to Qt-4.6.3 or above from their > distribution. Alternatively, you could temporarily deploy the above > workaround until essentially all distros have updated to 4.6.3 or > above. > > Finally, these issues remind me again that plpoin and plsym access > unicode glyphs in an indirect and extremely limited way. Therefore, I > have decided it is long past time we introduced a new function > plglyph(n, x, y, ucs4) which allowed plotting glyphs corresponding to > the ucs4 index for those drivers which are unicode aware. Such a > function would allow users full and direct access to the extremely > wide variety of generic sans and serif glyphs that are available on > their system for unicode-aware device drivers like qt (with Qt-4.6.3 > or later) or cairo. I will try implementing a first cut at plglyph > later today. > > 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 > __________________________ |