Menu
▾
▴
gnuplot-beta
|
From: Harald H. <h.h...@tu...> - 2005-02-05 16:09:44
|
Today, I have noticed that the currently available epslatex terminal has two bugs. Have a look at the output of this script: set terminal epslatex color 'default' 12 set output 'epslatex-orig1.eps' test set output set output 'epslatex-orig2.eps' set style line 1 lt rgb "#DA00A0" plot sin(x) w l ls 1 set output "gs epslatex-orig1.eps" results in "Error: /undefined in PolyFill" while "gs epslatex-orig2.eps" results "Error: /undefined in C". It is easy to fix these problems but I once again propose to apply my patch to cvs. The 'oldstyle' mode of today's version provides line styles, colors and symbols that are very similar to the ones of the old epslatex terminal (for those who did like the old behaviour). There has been positive feedback by Juergen Wieferink, Theo Hopman, and Andreas Keil. If you still have reservations to apply this patch please let me know why. Regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Daniel J S. <dan...@ie...> - 2005-02-05 23:36:47
|
Harald Harders wrote: >Today, I have noticed that the currently available epslatex terminal has >two bugs. Have a look at the output of this script: > >set terminal epslatex color 'default' 12 >set output 'epslatex-orig1.eps' >test >set output >set output 'epslatex-orig2.eps' >set style line 1 lt rgb "#DA00A0" >plot sin(x) w l ls 1 >set output > >"gs epslatex-orig1.eps" results in "Error: /undefined in PolyFill" while >"gs epslatex-orig2.eps" results "Error: /undefined in C". It is easy to >fix these problems but I once again propose to apply my patch to cvs. >The 'oldstyle' mode of today's version provides line styles, colors and >symbols that are very similar to the ones of the old epslatex terminal >(for those who did like the old behaviour). > >There has been positive feedback by Juergen Wieferink, Theo Hopman, and >Andreas Keil. > >If you still have reservations to apply this patch please let me know why. > > I recall this. If there are some others who've tried this patch and think it is an improvement, I'd say move it into CVS. On that note, I've placed a patch on SourceForge (1117060) that is a fix or enhancement for PostScript level 1 devices. It's been hanging around for a while. I've just updated the thing to accomodate the change in layout and variable names in post.term. The original code was a bit of work. The postscript code is tricky because it conditionally displays an image in the non "level1" setting depending upon whether the device is level 1 or not. The trick is that you can't just ignore the data there, it has to be "read in" from within the file itself so that PostScript doesn't think the data are commands and subsequently crashes. Anyway, it hasn't been tested by someone who has a true Level 1 printer (i.e., dinosaur). But I think it is an improvement. Doubt I will update the patch again unless I ever need Level 1 support for some strange reason. I've replaced some of the "fprintf"s with "fputs" for consistency with some recent changes to post.trm in CVS. Dan PS: Out of town for next 2 or 3 weeks. |
|
From: Petr M. <mi...@ph...> - 2005-02-08 11:06:16
|
> On that note, I've placed a patch on SourceForge (1117060) that is a fix > or enhancement for PostScript level 1 devices. It's been hanging around > for a while. I've just updated the thing to accomodate the change in > layout and variable names in post.term. The original code was a bit of > work. The postscript code is tricky because it conditionally displays > an image in the non "level1" setting depending upon whether the device > is level 1 or not. The trick is that you can't just ignore the data > there, it has to be "read in" from within the file itself so that > PostScript doesn't think the data are commands and subsequently crashes. > > Anyway, it hasn't been tested by someone who has a true Level 1 printer > (i.e., dinosaur). But I think it is an improvement. Doubt I will > update the patch again unless I ever need Level 1 support for some > strange reason. How much does it extend the file size? Is this Level1 code only for images? I think that a combination of someone printing images and using an obsolete (color?) postscript level 1 printer is very rare. Is the code put in only when "set term post level1" is specified? --- PM |
|
From: <ds...@ac...> - 2005-02-10 03:47:35
|
>> On that note, I've placed a patch on SourceForge (1117060) that is a f= ix >> or enhancement for PostScript level 1 devices. It's been hanging arou= nd >> for a while. I've just updated the thing to accomodate the change in >> layout and variable names in post.term. The original code was a bit o= f >> work. The postscript code is tricky because it conditionally displays >> an image in the non "level1" setting depending upon whether the device >> is level 1 or not. The trick is that you can't just ignore the data >> there, it has to be "read in" from within the file itself so that >> PostScript doesn't think the data are commands and subsequently crashe= s. >> >> Anyway, it hasn't been tested by someone who has a true Level 1 printe= r >> (i.e., dinosaur). But I think it is an improvement. Doubt I will >> update the patch again unless I ever need Level 1 support for some >> strange reason. > > How much does it extend the file size? Not by much. Here is the structure as I have changed it when level2 is allowed (i.e., user does not indicate "level1"): <conditional test for Level1> <if true> <draw a box with "this is level 2 image" inside> <if false> <a groupd of commands saying to "read from file" and ignore the next N by= tes of data in the file> <end conditional> \filter and other commands <big block of ASCII86 image data> With the added instructions, the "\filter" command is read and ignored.=20 Without them, "\filter" is an unrecognized command to level 1 and causes problems. The type bunch of code in ascii I'm guessing is 200 bytes or so (?). > > Is this Level1 code only for images? I think that a combination of some= one > printing images and using an obsolete (color?) postscript level 1 print= er > is > very rare. Is the code put in only when "set term post level1" is > specified? No, when level1 is specified, a level one readable image is included, not an ASCII86 filtered image. It is bulkier, but viewable to level 1 devices. The patch turns out to be fairly big because I put the ASCII85 encoding and in its own function, thereby shuffling around a lot of code. So ther= e is an ASCII85 routine, a regular level 1 image routine--both with the sam= e input/output structure. If someone wants a new encoding, say runlength (which some have asked for) this works out nicely because all it means no= w is a new subroutine similar to the existing two. Dan |
|
From: <ds...@ac...> - 2005-02-11 00:19:18
|
> The patch turns out to be fairly big because I put the ASCII85 encoding > and in its own function, thereby shuffling around a lot of code. So th= ere > is an ASCII85 routine, a regular level 1 image routine--both with the s= ame > input/output structure. If someone wants a new encoding, say runlength > (which some have asked for) this works out nicely because all it means = now > is a new subroutine similar to the existing two. I should clarify, the patch _file_ is big because of all the reorganizing= . However, the actual addition to the source code is fairly small. Dan |
|
From: Petr M. <mi...@ph...> - 2005-02-11 17:19:58
|
> The patch turns out to be fairly big because I put the ASCII85 encoding > and in its own function, thereby shuffling around a lot of code. So there > is an ASCII85 routine, a regular level 1 image routine--both with the same > input/output structure. If someone wants a new encoding, say runlength > (which some have asked for) this works out nicely because all it means now > is a new subroutine similar to the existing two. There is one failure in the patch, can you please update it? I can see there are two extraneous lines with "LT0" added to the output postscript files added, could this be avoided? Otherwise, the patch seems OK, so it could to cvs I think. -- PM |
|
From: Petr M. <mi...@ph...> - 2005-02-08 10:52:43
|
> If you still have reservations to apply this patch please let me know why. I've just added two minor corrections for docs, but otherwise I think it is ready for cvs. I will do it when you apply them. I hope people are comfortable with the new directory "share/" in cvs. The "pm3d/contrib" should be merged in it somewhen in future. --- PM |
