Re: pstricks export

[Lars Clausen <lars raeder dk>]

On Sat, 2005-12-03 at 19:51 +0800, Dean Scarff wrote:
> I can verify #143414 and #161636 (marked as a DUP).

Thank you!

> 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.
> See:
>
>   <http://tug.org/mailman/htdig/pstricks/2004/001692.html>
>
> 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
> aligned.

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
> container.
>
> 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

Good idea.

>   - 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

-- 
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