Re: pstricks export
- From: Lars Clausen <lars raeder dk>
- To: discussions about usage and development of dia <dia-list gnome org>
- Subject: Re: pstricks export
- Date: Sat, 03 Dec 2005 21:54:02 +0100
On Sat, 2005-12-03 at 19:51 +0800, Dean Scarff wrote:
I can verify #143414 and #161636 (marked as a DUP).
The relevant issue has come up on the pstricks mailing list a couple
of times. The cause is a conflict with the graphicx \scalebox macro.
The resolution is to switch to the new \psscalebox syntax (recent
versions of pstricks won't clobber \scalebox), with the arguments in
the same format as dia is using now.
I should be able to get that fixed for the upcoming release.
Nevertheless, the rendering at the moment is too naive to produce good
quality output: the text is undersized and the baseline is incorrectly
I am not surprise, nobody with an understanding of pstricks has looked
at it since we changed to Pango.
In regards to escaping for TeX ala tex_escape_string (there seems to
be some controversy in the comments), I think it's a good thing unless
Dia becomes smart enough to do its own TeX processing (like, say,
Ipe). If people put raw TeX code inside a Dia container expecting it
to look good after going through pstricks, they'll be disappointed.
The rendererd TeX won't have the same bounding box as the raw text
that Dia sees and the rendered text can underfill or overflow its
The extent of the escaping should be documented, and that
seemingly-innocent characters might not be translated faithfully.
Consider the "<" and ">" used in Dia UML diagrams for stereotypes.
Under the default (OT1) font encoding, they'll come up as inverted "!"
and "?" instead of the guillemets they are translated to in other
encodings. In general though, you can probably count on LaTeX users
to know what they're doing.
I poked a bit at making Dia call TeX to generate a bitmap. Technically
possible, but not too easy to define. Until such, pstricks text should
resemble what's shown in Dia, and thus a few escapes are necessary.
As a minor issue, it would be nice for pstricks hackers (and rendering
times, file sizes, etc) if the actual pstricks code was cleaner. Here
are a few easy optimisations:
- keep a static record of the last fill and line colour used, and
only print pstricks code to change the colour if necessary
- do the y-coordinate transformation in the filter so that
postscript isn't rendering upside down
A patch for this would be nice.
The attached patches are blind (I didn't have the necessary
dependencies on hand to rebuild), but they're not complex.
I'll take a look soon as I have time.
Lars Clausen (lars raeder dk, larsrc gmail com, http://lars.raeder.dk)
"I do not agree with a word that you say, but I will defend to the
death your right to say it."
--Evelyn Beatrice Hall paraphrasing Voltaire
] [Thread Prev