Menu
▾
▴
#275 xlabel, ylabel and title in plot and hardcopy doesn't work well
On hentoo linux 64 bits with the last git code, I get several errors with the following input file:
* test de titre
.control
set hcopydevtype = postscript
set hcopypscolor=1
set color2=rgb:F/0/0
let x = vector(5)
let y = exp(x)
plot y vs x xlabel 'Mon x' ylabel 'Mon y'
hardcopy plot_1.ps y vs x xlabel 'Mon X' ylabel 'Mon Y'
plot y vs x xlabel 'Mon x' title 'Mon titre'
hardcopy plot_2.ps y vs x xlabel 'Mon x' title 'Mon titre'
plot y vs x xlabel test
hardcopy plot_3.ps y vs x xlabel test
plot y vs x
hardcopy plot_4.ps y vs x
plot y vs x xlabel 'Labellisé X' ylabel 'Labellisée Y' title 'Titré'
hardcopy plot_5.ps y vs x xlabel 'Labellisé X' title 'Labellisé Y' title 'Titré'
.endc
First, the last hardcopy fail to create the plot_5.ps file with:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 58 requests (58 known processed) with 0 events remaining.
PPerror: syntax error
com_hardcopy: graph not defined
ERROR: (internal) tried to destroy non-existent graph
Second, when I right click on a plot, drag a rectangle, and release the click, it work fine when it is no xlabel, ylabel and title, and I get a new plot windows with only the selected area. But as soon it is 1 of them or a combination of them, I get the following error instead of a new plot:
title: no such command available in ngspice
or the same error with xlabel: or ylabel: instead of title:.
Third, when I write a label or a title like 'Title X', it appear like 'title x' without the quotes.
Last, a label or a title like 'Titré' give 'titrC)'.
~~~~~
:::html
Hello Dominique,
Thats quite a mess where you stumped upon.
First, the ngspice frontend is not 8bit clean,
there are ancient places in the source where the MSBit is used
for special purpose.
thus non plain ASCII chars are evil.
Then if you look at your example, the last hardcopy,
there you have two occurences of 'title'.
But the implementation of 'hardcopy' has a very simple minded
command line parser, as far as I can remember it looks just
for the first occurence of every possible 'command'-word.
This means it will leave the second 'title' on the list of arguments,
and then tries to process this as an another 'vector' name.
The 'Titr´e' at the end of line, will be processed as another "vector"
and triggers (probably due to 8bit) an error in the PP parser.
If you replace 'Titr´e' with some plain ASCII string, you won't get
a PPerror, but will be informed that there is no vector "title"
Third the 'drag' problem, I could not reproduce this here.
Please retry whether you can reproduce it, after replacing all
8 bit strings with plain ASCII.
Forth, the XIO: error, I could'nt reproduce this either.
Again, please retry with plain ASCII strings.
Robert
Issues remaining are:
Upper case letters in title etc will be converted to lower case.
Non plain ASCII in title are not recognized and are converted in an unexpected way.
Quotes in title etc are removed.
A rewrite of inpcom.c still has to be done.
Holger
A patch has been uploaded to development branch scope-inpcom-8. Extended ASCII is now allowed.
Holger
Thank you.
I try it. The only remaining issue here seam to be with extended ascii. I rewrote the last hardcopy as:
In the plot, the labels appear as "LabellisÃ? X" where ? is an unknow char to me, something similar to the copyright sign. In the ps file, I get: "Labellis^' X". Howeher, the ps file look good, which imply it must be a font issue or something else I don't know.
Last: the title doesn't appear in the ps file.
To confuse matters further, your plot_5.eps, when downloaded and rendered, looks like the bitmap below.
Maybe you should escape the critical "é" character and enter it as unicode?
-marcel
Manual input of e.g. a plot command now is o.k. We still have a problem with reading from a file.
inpcom.c, line 687
if (fgets(big_buff, 5000, fp))fgets does not do it correctly (MS Windows).
Holger
It is about the format used during storing the input *.cir file.
I am using notpad++ as editor. The standard setting for encoding was UTF8 w/o BOM. This is a UNICODE format not supported by ngspice.
If I change this and write out the input files as ASCII, then the correct characters are read into ngspice and displayed in the plot. "hardcopy" however is not yet o.k.
Holger
The contents in the resulting *.ps file seem to be o.k. (there are the French characters), but my Acrobat Distiller creates a pdf from the ps showing the figure with correct size and color, but not the correct text.....
Holger
I noted another effect: an e' character is read by the MSC run-time
isspace() function as an int with value -126. There is, however, an ASSERTE there that allows a character to have a value between -2 and 255.
This is only noticeable when debugging is ON and causes the search for the
text after "title" to fail. Title seems to be handled special for
hardcopy and does not behave like when used in a plot (I could be wrong, this became very complicated to follow in the debugger). Anyway, plot an gnuplot worked with the French characters, hardcopy did not.
-marcel
Last edit: marcel hendrix 2016-11-25
Holger,
chars beyond 127 don't have any semantic, except you know which charset
you are talking about. Whenever you hand such a char over to some function,
you need to make sure this one thinks about this char the same way as you intended.
In postscript this means, you need to care about Fonts, in X11 you need to load
the proper font sets etc etc. This gets complicated, escpecially concerning portability.
Things got a bit easier meanwhile, because utf-8 is now the by far most important
charset. You can forget everything else. because utf-8 takes care to avoid \x00 chars
in its multibyte sequences, the internals of ngspice might get away with utf8 too.
Still you would need to fix every DrawString, and the postscript prologe to actually
use utf-8 fonts.
I did experiments with UTF-8, modifying postsc.c to wide characters. With Visual Studio saving a file with fopen(..., " w, cc=UTF-8") leads to a Byte Order Mark (BOM) in the file header, which gsview and Acrobat Distiller acknowledge by stopping with error. Removing this BOM manually still does not give the correct postscript text output.
http://apps.jcns.fz-juelich.de/doku/sc/ps-latin offers a solution using single byte ascii, in that it enforces re-encoding. I have implemented this in postsc.c for Western European latin-1 (ISO/IEC 8859-1) encoding and tested with font Courier. Cyrillic encoding would need another encoding table (I do not have one at hand) as well as others.
Another problem has surfaced up: The command 'set hcopyfont=Courier' does not work because ngspice make it lower case, and the the font is not found afterwards. I have to check for that. The 'title' header is missing in the postscript output. I'm going to add it.
Holger
Last edit: Holger Vogt 2016-11-26
A small test case at hand:
A solution for ngspice with UNICODE support for file/folder names, titles and plot/gnuplot/hardcopy commands is now ready. Please see
https://sourceforge.net/p/ngspice/discussion/127605/thread/436da254/
Holger
Last edit: Holger Vogt 2017-01-25