IIRC there got something broken with Miktex 2.4, see
http://bugzilla.gnome.org/show_bug.cgi?id=143414
But I'm not a Tex expert so you may want to provide
more info - i.e. what in the output should change
and how.

Hello, thanks for the reply. First of all I put the duplicate entry not to increase priority, but because I accidently choose Dia version 0.92-pre2 instead of 0.95-pre2. Anyway, here a list of changes to make the TeX export work:

1) \ and $ in texts are escaped by \, which causes the LaTeX error:
   
  '! LaTeX Error: Something's wrong--perhaps a missing \item.'
  
thus change '\\' to '\' and '\$' to $ 

2) the text does not occur because the second coordintate of rput has a wrong sign, change '\rput[l](x,y)' to '\rput[l](x,-y)'

(these two first issues are new to version 0.952, version 0.94 didn't do that!)

3) the repetition of the colour definition:
 
   '\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}'

causes the lines to be misplaced, thus remove this unessesary repetitions (we only use black & white drawings, might be interesting to discover what happens if you use different colours, where the re-definition is needed. This might be solved by using '\newrgbcolor{dialinecolor1}', '\newrgbcolor{dialinecolor2}', etc...)

4) the font defintions

   '\setfont{Helvetica}{0.800000}'

are also reated, don't cause trouble yet. However, it might be a good choice to remove also that repetitions.

5) to my knowledge the syntax for the 'scalebox' as used in the tex export is not up to date.  Thus change 

   '\scalebox{a b}' to '\scalebox{a}[b]'

(As soon as you want to resize your drawings in Latex (which is always required for my applications) using the '\resizebox' command of the 'graphicx' package, there is a conflict between the two 'scalebox' definitions. As I mentioned before, I avoided that problem in the past by commenting the scalebox definition in graphics.sty, which might not be a recommended way ;-) )

Hans,

Jens is using the win32 version of Dia, which may be hard to build from CVS. I am willing to test your changes on my Linux box. I have been facing the same problems since 0.94 which forbid me to update tetex from 2.x to 3.x. 

I hope the described change will be sufficient, but it may require more changes in the way the tex file is created, especially for more complex diagrams. For instance, it will be better to describe at the beginning of the file, all the colors to be used: e.g.

\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}
\newrgbcolor{dialinecolor1}{1.000000 0.000000 0.000000}
\newrgbcolor{dialinecolor2}{0.000000 1.000000 0.000000}
...
\newrgbcolor{dialinecolorn}{0.000000 0.000000 1.000000}

and just used the appropriate color when required:e.g.

...
\setcolor{dialinecolor2}
...

to avoid the issue described in 3) in Comment #2

Want to fix this one, but not tonight.

1) partly right, \, [, and ] were wrongly escaped, but $ is fine.  There's a sample in the sample dir now.

2) is a fix that Hans made explicitly.  Hans, care to comment?

3) and 4) could be done with a pre-pass -- xfig has a kinda hacky one, would be neat with a generic one.

Sure, already done ;)

http://cvs.gnome.org/viewcvs/dia/plug-ins/pstricks/render_pstricks.c?rev=1.25&view=log

gives:

2006-01-14  Hans Breuer  <hans@breuer.org>

	* plug-ins/pstricks/render_pstricks.c(draw_string) : now that I've
	found the nice samples from bug #156171 it was quite simple to
	confirm that the y value need indeed to be inverted. Fixes bug #304974
	Also special case strings starting with \tex - i.e. dont escape them -
	to keep the use-case of direct tex input.

Created attachment 60833 [details]
Sample for pstricks export scalebox command

Hans, with respect to bug #156171 comment #2: if you use the package psfrags, you cannot convert dvi2pdf directly (I think that's what 'dvipdf' does, rightt?), you have to convert to ps first and then to pdf.

What about the change of the 'scalebox' syntax? I uploaded an attachment, which shows a case where this does not work until you change the syntax of scalebox as mentioned in <a name="c2" href="show_bug.cgi?id=333193#c2">#2</a> 5).

Lars, why should the escape sequence before '$' be right?

Because the below is a valid LaTeX document?

\documentclass{article}

\begin{document}

Please send me \$100,000.

\end{document}

Lars,

I don't fully understand the logic here! If a user is exporting a DIA diagram in .tex, for sure he/she is aware that to display a `$', he/she will need to add a backslash before! Meanwhile, I guess that most of the tex users will be more interested in the ability to add mathematical notation as such: $y_{k}$ to have it displayed properly in their .ps/.pdf documents! 

Is this change of behavior of DIA not a regression/bug with respect to previous release?

1) Escaping and \tex
Ok, after checking the source code and bug #156171 i realise whats going on. From now on you need to use \tex to get latex source code through the dia pstricks export. To be honest, I don't see a real benefit in that, since it just means more typing effort. Moreover, the need of defining the fake '\tex' command doesn't make life easier for users, it only leads to more confusion. A user of the pstricks export, who uses latex would obviously be aware to escape critical signs, such as $, himself if he wanted to appear the $-sign in the text, rather than entering the math mode. So why did you introduce that \tex business in the first place?

2) \scalebox, PSTricks and Graphicx
With the risk to be a pain in the ass, again I wonna mention the problems arising using the graphicx package in addition with PSTricks and the resulting problems. Here some ugly facts:

I)   PStricks uses the syntax: \scalebox{x y}{...}

II)  Graphics uses the syntax: \scalebox{x}[y]{...}

III) as soon as you include a package of the graphics family, you cannot use the dia export anymore, since the syntax of I) is used, which yields the latex error: "! Illegal unit of measure (pt inserted)." (cf. ex1.tex)

IV)  if you modify all scalebox command according to the syntax of II) in the exported tex file, it works fine again, as long as the graphicx package is also included! (cf ex2.tex)

I am well aware of the fact that this is fundamentally a latex problem of command-definition conflict between the two mentioned packages rather than a problem the dia developers should be bothered with. However, I would recommend to change the the scalebox syntax of the Dia pstricks export to that of Graphics and advise the dia users to include both packages grapchicx as well as pstricks, as long as this definition-mismatch exists. This has got the advantage, that users then can also use the features of graphics, such as rescaling the size of the included dia exports. Again, in my eyes features of the graphicx package are needed in combination with the dia pstricks-export in most applications. As mentioned before, adrawback of this is change would be that the grphicx package has to be included all the time (in addition to the pstricks package). But in my eyes this would be more beneficial than the existing solution, which doesnt take the problem into account.

(I will upload some examples, which illustrate the problems of 2)) 

Created attachment 61096 [details]
illustrates the problems using DIA PSTricks export together with the graphicx package in latex

Diagram1.dia: a simple Diagram created with Dia 095-pre4 on win32
orgPSTricksExport.tex: the original PSTricks export of Diagram1 
mod1PSTricksExport.tex: the PSTricks export of Diagram1 using modified scalebox syntax
ex1.tex: shows the latex error when graphicx package is included
ex2.tex: shows that the dia export can be used with the grapchicx package, if the scalebox syntax is changed

The macro \scalebox in PStricks is renamed to \psscalebox with the same syntax.
To prevent mismatches with the \scalebox from graphicx there is no more support for the old macro.

and by the way: DIA should use the _new_  syntac for defining colors:

\definecolor{name}{model}{...}

The LaTeX version of PSTricks has full support for the xcolor package.
The old syntax \newrgbcolor and others, should be used only for a real TeX-export.

moving away from *-pre* to remove them

Can't be on already passed 0.95 milestone. I'm a uncertain about dropping comaptibility with older TeX versions. Is it common to constantly update your TeX installation?

(In reply to comment #2)
> 1) \ and $ in texts are escaped by \, which causes the LaTeX error:

I liked to old capability to use tex commands directly in dia labels - it is
advertised by the dia FAQ, and still works in the metpost exporter.

> 2) the text does not occur because the second coordintate of rput has a wrong
> sign, change '\rput[l](x,y)' to '\rput[l](x,-y)'

I think this problem was caused by an attempt to make the exported figures
render correctly in xdvi - this change from 2006-01-14 should be reverted
(see patch).

> 3) the repetition of the colour definition:
> 
>    '\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}'
> 
> causes the lines to be misplaced, thus remove this unessesary repetitions (we
> only use black & white drawings, might be interesting to discover what happens
> if you use different colours, where the re-definition is needed. This might be
> solved by using '\newrgbcolor{dialinecolor1}', '\newrgbcolor{dialinecolor2}',
> etc...)

Using a new name for each color does not fix the spacing - but putting a comment
character before the newline after each \newrgbcolor command does (see patch).

> 4) the font defintions
> 
>    '\setfont{Helvetica}{0.800000}'
> 
> are also reated, don't cause trouble yet. However, it might be a good choice to
> remove also that repetitions.

(worth doing if a pre-pass is ever implemented)

> 5) to my knowledge the syntax for the 'scalebox' as used in the tex export is
> not up to date.  Thus change 
> 
>    '\scalebox{a b}' to '\scalebox{a}[b]'
> 
> (As soon as you want to resize your drawings in Latex (which is always required
> for my applications) using the '\resizebox' command of the 'graphicx' package,
> there is a conflict between the two 'scalebox' definitions. As I mentioned
> before, I avoided that problem in the past by commenting the scalebox
> definition in graphics.sty, which might not be a recommended way ;-) )

This has been fixed now, by replacing \scalebox with \psscalebox

Created attachment 86383 [details] [review]
do not change sign of y co-ord for text label, no space after \newrgbcolor

(In reply to comment #2)
> 1) \ and $ in texts are escaped by \, which causes the LaTeX error:

I liked the old capability to use tex commands directly in dia labels - it is
advertised by the dia FAQ, and still works in the metpost exporter.

> 2) the text does not occur because the second coordintate of rput has a wrong
> sign, change '\rput[l](x,y)' to '\rput[l](x,-y)'

I think this problem was caused by an attempt to make the exported figures
render correctly in xdvi - this change from 2006-01-14 should be reverted
(see patch).

> 3) the repetition of the colour definition:
> 
>    '\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}'
> 
> causes the lines to be misplaced, thus remove this unessesary repetitions (we
> only use black & white drawings, might be interesting to discover what happens
> if you use different colours, where the re-definition is needed. This might be
> solved by using '\newrgbcolor{dialinecolor1}', '\newrgbcolor{dialinecolor2}',
> etc...)

Using a new name for each color does not fix the spacing - but putting a comment
character before the newline after each \newrgbcolor command does (see patch).

> 4) the font defintions
> 
>    '\setfont{Helvetica}{0.800000}'
> 
> are also reated, don't cause trouble yet. However, it might be a good choice to
> remove also that repetitions.

(worth doing if a pre-pass is ever implemented)

> 5) to my knowledge the syntax for the 'scalebox' as used in the tex export is
> not up to date.  Thus change 
> 
>    '\scalebox{a b}' to '\scalebox{a}[b]'
> 
> (As soon as you want to resize your drawings in Latex (which is always required
> for my applications) using the '\resizebox' command of the 'graphicx' package,
> there is a conflict between the two 'scalebox' definitions. As I mentioned
> before, I avoided that problem in the past by commenting the scalebox
> definition in graphics.sty, which might not be a recommended way ;-) )

This has been fixed now, by replacing \scalebox with \psscalebox

I have applied your patch.  I hope the sign is not going to undergo further changes:)  

For comment #16: "works in the metpost exporter." -- works with the exception that Dia is all confused about the size of the text compared to the actual output.  That is really an issue for a different bug, but there's a definite TeX-related issue with escaping/not escaping and text size.  

Hello
(In reply to comment #2)
> 2) the text does not occur because the second coordintate of rput has a wrong
> sign, change '\rput[l](x,y)' to '\rput[l](x,-y)'
> 
> (these two first issues are new to version 0.952, version 0.94 didn't do that!)

I have a similar problem, cf my TeX script below.

With this line it works (just changing the sign of 3.662500) :
\rput[l](4.081250,3.662500){\psscalebox{1 -1}{This is a test text}}

Best regards

******************************************
\ifx\setlinejoinmode\undefined
  \newcommand{\setlinejoinmode}[1]{}
\fi
\ifx\setlinecaps\undefined
  \newcommand{\setlinecaps}[1]{}
\fi
% This way define your own fonts mapping (for example with ifthen)
\ifx\setfont\undefined
  \newcommand{\setfont}[2]{}
\fi
\pspicture(4.081250,-3.745375)(5.498938,-3.489812)
\psscalebox{1.000000 -1.000000}{
\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}
\psset{linecolor=dialinecolor}
\newrgbcolor{diafillcolor}{1.000000 1.000000 1.000000}
\psset{fillcolor=diafillcolor}
\setfont{Helvetica}{0.200000}
\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}
\psset{linecolor=dialinecolor}
\rput[l](4.081250,-3.662500){\psscalebox{1 -1}{This is a test text}}
}\endpspicture

PS/ I am using :

Dia v0.96.1
pdfTeX, Version 3.141592-1.40.7 (MiKTeX 2.7)
TeXnic Center 1 beta 7.01

and these packages only :

\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[english]{babel}
\usepackage{pstricks}

The behaviour is absolutely correct:

\listfiles
\documentclass{minimal}
\usepackage{pstricks}

\begin{document}

\pspicture[showgrid=true](4,-3.75)(5,3.8)
\psscalebox{1 -1}{%
\rput[l](4.081250,-3.662500){This is a test text}
\rput[l](4.081250,-3.662500){\psscalebox{1 -1}{This is a test text}}%
}
\endpspicture

\end{document

The first psscalebox reflects the y-axes, negative values will
be positive and vice versa. A \rput[l](4.081250,-3.662500)
is the same as a \rput[l](4.081250,3.662500) without a psscalebox.
The second psscalebox refers only to the internal current point,
which is 4.081250,-3.662500 inside the outer psframebox or
absoloutely 4.081250,3.662500. To this point the inner psscalebox
reflects the text releative to the horizontal line.

Herbert

Thanks Herbert for your quick reply. I understand things "better"....

Yet after doing several tests the TeX script Dia generates still doesn't work. I wonder if the problem isn't rather comming from the \pspicture coordinates.

You can have a try yourself : I have attached an example file : tex_export_problem.dia

And here is below the script generated automatically from the dia file.

Best regards

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\ifx\setlinejoinmode\undefined
  \newcommand{\setlinejoinmode}[1]{}
\fi
\ifx\setlinecaps\undefined
  \newcommand{\setlinecaps}[1]{}
\fi
\ifx\setfont\undefined
  \newcommand{\setfont}[2]{}
\fi
\pspicture(5.135000,-11.325202)(8.715000,-10.127702)
\psscalebox{1.000000 -1.000000}{
\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}
\psset{linecolor=dialinecolor}
\newrgbcolor{diafillcolor}{1.000000 1.000000 1.000000}
\psset{fillcolor=diafillcolor}
\setfont{Helvetica}{1.000000}
\newrgbcolor{dialinecolor}{0.000000 0.000000 0.000000}
\psset{linecolor=dialinecolor}
\rput[l](5.135000,-10.972700){\psscalebox{1 -1}{Test text}}
}\endpspicture

Created attachment 109409 [details]
Example of text display problem while exporting to TeX

This bug was fixed in the source tree on 2007-04-16, after the
release of Dia v0.96.1.  Have you tried compiling from the current source tree?

I understand now...
No I didn't try recompiling. I think I will wait for the next release and in the mean time use export to Eps or Pdf.

Thanks for your help !

(In reply to comment #25)
> This bug was fixed in the source tree on 2007-04-16, after the
> release of Dia v0.96.1.  Have you tried compiling from the current source tree?
>