r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Postscript] Emitting Postscript from REBOL

Geomol
24-Feb-2008
[1452]
If you look in postscript.r, I encode the image data in line 211-220. 
It's just normal hex written as ASCII, so you get '0'-'9' + 'A'-'F'.
Henrik
24-Feb-2008
[1453x2]
when building the image data, how do you do that? or does ASCIIHexDecode 
do that?
ok
Geomol
24-Feb-2008
[1455]
So this is very simple encoding. ASCII85 encoding is a bit more difficult, 
but will take up less space.
Henrik
24-Feb-2008
[1456x3]
perhaps it's equal in speed, I don't know. odd though, I can't see 
what's so slow about that code, other than the newline insertion 
thing
perhaps inserting in images is very slow?
does it need to be done?
Geomol
24-Feb-2008
[1459x2]
It seems to work without the newlines, but then the ps file become 
difficult to enter with e.g. vim. That part is fast, I think. It 
only put in a newline for every 80 chars.
My guess is, that it's the load-image/update that give you performance 
hit. Try change it!
Henrik
24-Feb-2008
[1461x3]
it does not, I tried a local file. 12 seconds.
will try to add some profiling hints
nope, it's the inserting part. the rest is taking no time at all.
Geomol
24-Feb-2008
[1464]
You say, you tried a local file, but did you change the load-image 
in postscript.r?
Henrik
24-Feb-2008
[1465]
so I think there should be an option to leave that out, or by default 
not have it. I'm guessing most people want to generate and print 
PS file, rather than read and edit them by hand.
Geomol
24-Feb-2008
[1466]
ok, the inserting of the newlines is the problem?
Henrik
24-Feb-2008
[1467x2]
didn't try that with /update yet. will have to be sure
yep, same thing without /update.
Geomol
24-Feb-2008
[1469]
If the inserting is the problem, then I might be able to fix that 
with copy to another series in stead. Problem with insert is, when 
you have large series, it has to move the content down the memory.
Henrik
24-Feb-2008
[1470x2]
I'm trying to remove that code right now to see if it improves performance.
now GS won't read the PS file, but the generation is much much faster. 
less than 0.5 secs
Geomol
24-Feb-2008
[1472]
Just uncomment after the trim in line 213.
Henrik
24-Feb-2008
[1473]
did that
Geomol
24-Feb-2008
[1474x3]
ok :)
Ok, I'll see, if I can make a faster insert...
Henrik, try with new version now:
http://home.tiscali.dk/john.niclasen/postscript/postscript.r
Henrik
24-Feb-2008
[1477x4]
odd, GS won't eat it
oh, error 40 :-)
much faster now and it works
tried a much bigger image. no problems at all.
Geomol
24-Feb-2008
[1481]
Great! That's the version to use for now then. Maybe I should put 
an announce in that group?
Henrik
24-Feb-2008
[1482x2]
go ahead :-)
BTW: Does it work for you in preview.app?
Geomol
24-Feb-2008
[1484]
Yes, it works in preview now. :-)
Henrik
24-Feb-2008
[1485x2]
so for the other bug: I mentioned earlier that some printers I tried 
it on directly, will cause the printer to pause after the first page 
is printed. Then I need to press paper feed or reset the printer 
to get the rest out. Using Printfile for Windows solves that, but 
that program is really old and I don't want to rely on it in the 
future if my project is moved to Linux clients. I suspect there is 
just one char missing at the end of the PS file, but I don't truly 
know what causes it.
an important detail: I don't think it's single print jobs of multiple 
pages that cause it, but rather multiple single page jobs.
Geomol
24-Feb-2008
[1487x2]
To do anything about it, we need to be able to reproduce that error, 
and see if we can figure out, that might solve it. A way to test 
different things is to edit the ps-files by hand.
that = what
Henrik
24-Feb-2008
[1489x4]
what I do to cause the error is make a ps file with postscript.r 
and then feed it directly to the printer. In windows I print directly 
to LPT1: to produce it. Under Linux I print it via LPR.
I've seen the bug in two separate HP laser printers
no, sorry, under Linux I also print to the device directly. LPR was 
when I used PDF for printing rather than PS.
a simple check: does a PS example from the internet end the same 
way as a postscript.r generated file?
Geomol
24-Feb-2008
[1493]
Output from TextEdit printed to a PS file has this in the end:

%%Trailer
%%Pages: 1
%%EOF
^D


The last char (ctrl-D) is hex 04. I think, the comment lines are 
according to "PostScript Language Document Structuring Conventions 
Specification". You can find this document on the net at Adobe. So 
there is a difference in how %%Pages comments are handled. And postscript.r 
doesn't put hex 04 in the end. You could try some of these changes, 
when you have the problem.
Henrik
24-Feb-2008
[1494]
I'll give it a shot when I get access to the testing equipment.
Geomol
26-Feb-2008
[1495x2]
Updated the documentation:
http://home.tiscali.dk/john.niclasen/postscript/postscript.html
Added describtion of comment.
Has anyone tried the transformations? There might be an unwanted 
restriction in the implementation. I can't get transformations to 
work for a whole page, only for one path at a time.
Henrik
26-Feb-2008
[1497]
I've only tried transformations for single paths, sorry.
Geomol
26-Feb-2008
[1498]
Do you use right-aligned text?
Henrik
26-Feb-2008
[1499]
it has worked fine in the past, I believe
Geomol
26-Feb-2008
[1500]
Yes, but it only worked with integer! text-size. I've added decimal! 
option, and this seems to work too. (sub-unit precision)
I have a new version ready soon.
Henrik
26-Feb-2008
[1501]
cool :-)