Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #858 > unrolled thread

(embarrassingly) simple showpage question

Back to article view | Back to comp.lang.postscript

Contents

  (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 04:58 +0000
    Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-08 07:59 +0100
      Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 08:54 +0000
        Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-08 10:17 +0100
          Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-08 10:08 +0000
            Re: (embarrassingly) simple showpage question tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2012-08-08 22:07 -0400
              Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-09 05:40 +0000
                Re: (embarrassingly) simple showpage question ken <ken@spamcop.net> - 2012-08-09 08:44 +0100
                  Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-09 09:38 +0000
                  Re: (embarrassingly) simple showpage question JohnF <john@please.see.sig.for.email.com> - 2012-08-10 06:24 +0000

#858 — (embarrassingly) simple showpage question

I want to create a two/many-page document, e.g., so that gv shows
it as two/many pages and allows you to navigate among them.
Couldn't find a simple explanation in PLRM or any-color-book.ps,
and the little snippet at the bottom of this post just doesnt't work,
no matter how I try messing with it. With the first showpage
commented, as shown, both pages display overlaid as one page.
Uncommented, only the first page shows, and the second is
inaccessible.
   I tried using ImageMagick convert to combine two small one
page docs,
     convert doc1.ps doc2.ps twopagedoc.ps
and that works fine. But vi-ing the twopagedoc, I can't for the
life of me figure out what it's doing that I'm not, or what
it's doing right that I'm doing wrong, or whatever. I tried
various things like gsave/grestore, just for kicks, but nothing
seems to have any effect. What's the trick? Thanks,

%!PS
%%Creator: tester
%%CreationDate: now
%%Title:       tester

1.08 1.08 scale
33.33 116.67 translate

%%Page:  1 1
%gsave
newpath
290 320 moveto
0 214 lineto
11 209 moveto
283 318 lineto
275 317 moveto
23 204 lineto
1 setlinewidth
0.00 0.00 0.78 setrgbcolor
stroke
%showpage
%grestore

%%Page:  2 2
%gsave
newpath
260 344 moveto
112 69 lineto
122 71 moveto
252 345 lineto
244 347 moveto
131 73 lineto
1 setlinewidth
0.00 0.00 0.78 setrgbcolor
stroke
showpage
%grestore

%%EOF
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [next] | [standalone]

#859

In article <jvsrl9$npu$1@reader1.panix.com>, 
john@please.see.sig.for.email.com says...

> seems to have any effect. What's the trick? Thanks,

You can't normally 'navigate' around a PostScript file, because its not 
designed that way, there is no way to tell where one page starts and 
another ends (without interpreting the whole document). In addition its 
perfectly possible to have a PostScript program which only works if you 
execute the pages in the correct order, because later pages rely on 
definitions from earlier pages, such as fonts.

In order to permit this navigation the file needs to be DSC (Document 
Structuring Convention) compliant. That is, it needs to have certain 
comments present to enable the application to know how many pages are in 
the program, and where the beginning of each one is, and also needs to 
be constructed so that each page is atomic (or at least relies only upon 
setup done in a defined, commented, section)

Ideally it also needs to know the size of each page. Your example, while 
perfectly sound PostScript, doesn't conform to DSC, and this is almost 
certainly why it doesn't work as you exepct. 

I don't know exactly what it is that the application in question needs 
to allow this to happen, but I would imagine at least a '%%Pages: 2'. 
Your file also *must* declare itself as being DSC-compliant, this is 
done by altering the conventional %!PS comment to one of the form %!PS-
Adobe-x.y where x and y are the major and minor revision numbers of the 
DSC specification which the document complies with.

Tech Note 5001 (available somewhere on the Adobe web site) documents 
DSC.



				Ken

[toc] | [prev] | [next] | [standalone]

#860

ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...
> 
>> seems to have any effect. What's the trick? Thanks,

Thanks, Ken,...

> You can't normally 'navigate' around a PostScript file, because its not 
> designed that way, [...]

My bad saying "navigate". I just meant it colloquially.
Ghostview displays a bar with page numbers allowing you
to click any page number to view that page. That bar's
empty when the document has only one page, and that's
what I was seeing -- an empty "navigation bar".

> Your example doesn't conform to DSC, and this is almost 
> certainly why it doesn't work as you exepct. 
> I would imagine [it needs] at least a '%%Pages: 2'. 

Nope, at least in this case it didn't need a %%Pages: n
in the prolog (which is fortunate because the program generating
the ps file won't know how many pages the file will have when it
opens and initializes the file). But it >>did<< need a %%Page: 1 1
and a %%Page: 2 2, etc, at the beginning of each page.

> Your file also *must* declare itself as being DSC-compliant,
> by altering %!PS to one of the form %!PS-Adobe-x.y

Yup, that seems to have been my major blunder. Changing
my %!PS to your %PS-Adobe-3.0 did the trick. Apparently, I looked
at everything in the ImageMagick convert example >>except<<
its absolutely very first line. It was right there in front of
me all along, and I'd definitely have tried that change
had I noticed it.

> Tech Note 5001 (available somewhere on the Adobe web site)
> documents DSC.

Yeah, I did come across several of those 500x- docs googling
"postscript page numbers" and stuff like that, trying to
figure it out myself. All I could think of doing was looking at
the document indexes or table of contents (when available) for
showpage and Page, etc. But nothing that I could find that way
seemed to address creating multiple-page documents.
I'd have thought it would be one of the first things any
ps language tutorial would mention.
Thanks again, Ken,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#861

In article <jvt9gu$sgj$1@reader1.panix.com>, 
john@please.see.sig.for.email.com says...

> > Your example doesn't conform to DSC, and this is almost 
> > certainly why it doesn't work as you exepct. 
> > I would imagine [it needs] at least a '%%Pages: 2'. 
> 
> Nope, at least in this case it didn't need a %%Pages: n
> in the prolog (which is fortunate because the program generating
> the ps file won't know how many pages the file will have when it
> opens and initializes the file). But it >>did<< need a %%Page: 1 1
> and a %%Page: 2 2, etc, at the beginning of each page.

"%%Pages; (atend)" with a matching "%%Pages: " in the trailer is an 
acceptable way to resolve this problem, its a commonly used construct 
for exactly this reason.

 
> > Your file also *must* declare itself as being DSC-compliant,
> > by altering %!PS to one of the form %!PS-Adobe-x.y
> 
> Yup, that seems to have been my major blunder. Changing
> my %!PS to your %PS-Adobe-3.0 did the trick. Apparently, I looked
> at everything in the ImageMagick convert example >>except<<
> its absolutely very first line. It was right there in front of
> me all along, and I'd definitely have tried that change
> had I noticed it.

Its easily missed, indeed the fact that all the DSC relies on comments 
can make it very easy to miss altogether....

> showpage and Page, etc. But nothing that I could find that way
> seemed to address creating multiple-page documents.
> I'd have thought it would be one of the first things any
> ps language tutorial would mention.

Well its not strictly the PostScript language, interpreters are 
permitted to ignore comments altogether, the DSC comments are only used 
by document parsing applications (like Ghostview).

DSC is an old extension, when it became apparent that people wanted to 
be able to look at PostScript files, not just print them :-) I guess 
Adobe didn't want to break the concept of streamable files for printing, 
so they came up with a way which worked 'well enough' without altering 
the language at all.

This is pretty much superceded by PDF these days, which has a clear 
structure for jumping around inside the file, and clearly defined start 
and end of pages and resources, so it all works much better. DSC does 
still have uses in printing because a lot of the document processing 
applications still use the comments to rearrange documents, impose them 
onto signatures and so forth.

> Thanks again, Ken,

No problem, I'm glad you got it working so easily,


			Ken

[toc] | [prev] | [next] | [standalone]

#862

ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...
> 
>> > Your example doesn't conform to DSC, and this is almost 
>> > certainly why it doesn't work as you exepct. 
>> > I would imagine [it needs] at least a '%%Pages: 2'. 
>> 
>> Nope, at least in this case it didn't need a %%Pages: n
>> in the prolog (which is fortunate because the program generating
>> the ps file won't know how many pages the file will have when it
>> opens and initializes the file). But it >>did<< need a %%Page: 1 1
>> and a %%Page: 2 2, etc, at the beginning of each page.
> 
> "%%Pages: (atend)" with a matching "%%Pages: " in the trailer is an 
> acceptable way to resolve this problem, its a commonly used construct 
> for exactly this reason.

Thanks, Ken, I'll program that in, too. And now that you've
mentioned it, I've googled it for more info. But there's no
way I could have discovered it on my own beforehand (except
sheer dumb luck).

>> > Your file also *must* declare itself as being DSC-compliant,
>> > by altering %!PS to one of the form %!PS-Adobe-x.y
>> 
>> Yup, that seems to have been my major blunder. Changing
>> my %!PS to your %PS-Adobe-3.0 did the trick. Apparently, I looked
>> at everything in the ImageMagick convert example >>except<<
>> its absolutely very first line. It was right there in front of
>> me all along, and I'd definitely have tried that change
>> had I noticed it.
> 
> Its easily missed, indeed the fact that all the DSC relies on comments 
> can make it very easy to miss altogether....
> 
>> showpage and Page, etc. But nothing that I could find that way
>> seemed to address creating multiple-page documents.
>> I'd have thought it would be one of the first things any
>> ps language tutorial would mention.
> 
> Well its not strictly the PostScript language, interpreters are 
> permitted to ignore comments altogether, the DSC comments are only used 
> by document parsing applications (like Ghostview).
> 
> DSC is an old extension, when it became apparent that people wanted to 
> be able to look at PostScript files, not just print them :-) I guess 
> Adobe didn't want to break the concept of streamable files for printing, 
> so they came up with a way which worked 'well enough' without altering 
> the language at all.
> 
> This is pretty much superceded by PDF these days, which has a clear 
> structure for jumping around inside the file, and clearly defined start 
> and end of pages and resources, so it all works much better. DSC does 
> still have uses in printing because a lot of the document processing 
> applications still use the comments to rearrange documents, impose them 
> onto signatures and so forth.

I googled "pdf programming", which doesn't seem quite so straightforward
as ps, and way fewer documents discussing it, as far as I could tell.
I've had several assembly programming jobs (now mostly C), so ps doesn't
really seem intimidating, if less well structured. But pdf seemed pretty
opaque to me at first blush.

>> Thanks again, Ken,
> No problem, I'm glad you got it working so easily,

Well, needle in haystack -- easy to remove, hard (for me) to find.
I wasted half a dozen hours, convinced that with the working
"convert page1.ps page2.ps twopages.ps" example in hand,
I ought to be able to quickly find the relevant difference
with my non-working example. (And now that you've explained it,
I should have.) Thanks,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#867

On Wed, 8 Aug 2012 10:08:22 +0000 (UTC), JohnF wrote:

>  But there's no
> way I could have discovered it on my own beforehand (except
> sheer dumb luck).

Indeed, if YaBinOogling is fishing, success lies entirely in knowing -- or
stumbling upon -- what to use as -- and how to cut -- your bait :-) .

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#868

tlvp <mPiOsUcB.EtLlLvEp@att.net> wrote:
> On Wed, 8 Aug 2012 10:08:22 +0000 (UTC), JohnF wrote:
>> But there's no way I could have discovered it
>> on my own beforehand (except sheer dumb luck).
> 
> Indeed, if YaBinOogling is fishing, success lies
> entirely in knowing -- or stumbling upon -- what
> to use as -- and how to cut -- your bait :-) .
> Cheers, -- tlvp

Thanks again, Ken. First cut is pretty much done, i.e.,
pretty much working as intended. An example is at
  http://www.forkosh.com/decorative/decofweek.ps
intended to be input into ImageMagick's
  convert -delay 0 -loop 0 input.ps output.gif
whose corresponding output is at (you guessed it)
  http://www.forkosh.com/decorative/decofweek.gif

The reason I mention all that is because the gif's
5MB, and convert took 6mins to render it from ps
on an i7-920 (though only utilizing one core).
   That's at least partly because I couldn't originally
figure out how to get a transparent background.
So the first %%Page contains one lineto, the second page
contains two, ..., the hundredth/last contains 100 (total 5050).
A smaller and faster version using
  convert -transparent "#FFFFFF" -delay 0 -loop 0 input.ps output.gif
whose input/output is at
  http://www.forkosh.com/decorative/decofweek-v2.ps
  http://www.forkosh.com/decorative/decofweek-v2.gif
works with each %%Page containing only one line (total 100),
and the transparent background lets those lines build up.

But the v2-file's still 350KB and convert takes 31secs,
which is still too slow for online world use. ImageMagick
convert runs gs for its ps-->gif conversion, driven by a
delegates.xml file (in /usr/lib/ImageMagick-6.4.3/config/
on my box) containing the line
  <delegate decode="ps:color" command="---see below---"/>
where command is
  gs -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT
     -sDEVICE=pnmraw
     -and-some-other-stuff
Trying to speed it up, I naively tried psrgb instead of pnmraw,
but that just took longer. Is there any way for gs to
more quickly (i.e., less slowly) run this ps-->gif conversion
with a transparent background?
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#869

In article <jvvigi$fm2$1@reader1.panix.com>, 
john@please.see.sig.for.email.com says...
 
> The reason I mention all that is because the gif's
> 5MB, and convert took 6mins to render it from ps
> on an i7-920 (though only utilizing one core).

Well it is 100 pages of output, and each page is of steadily increasing 
complexity.

>    That's at least partly because I couldn't originally
> figure out how to get a transparent background.
> So the first %%Page contains one lineto, the second page
> contains two, ..., the hundredth/last contains 100 (total 5050).
> A smaller and faster version using
>   convert -transparent "#FFFFFF" -delay 0 -loop 0 input.ps output.gif
> whose input/output is at
>   http://www.forkosh.com/decorative/decofweek-v2.ps
>   http://www.forkosh.com/decorative/decofweek-v2.gif
> works with each %%Page containing only one line (total 100),
> and the transparent background lets those lines build up.

Hmm, PostScript doesn't support transparency, not at all. So ImageMagick 
must be treating the untouched background as transparent, I've no idea 
how it is doing that.

Also, of course, PostScript doesn't output animations, since its 
intended as a printing langage, so the animated GIF is presumably 
assembled by ImageMagick. I don't know anything about the application 
I'm afraid.

 
> But the v2-file's still 350KB and convert takes 31secs,
> which is still too slow for online world use. ImageMagick
> convert runs gs for its ps-->gif conversion, driven by a
> delegates.xml file (in /usr/lib/ImageMagick-6.4.3/config/
> on my box) containing the line
>   <delegate decode="ps:color" command="---see below---"/>
> where command is
>   gs -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT
>      -sDEVICE=pnmraw
>      -and-some-other-stuff
> Trying to speed it up, I naively tried psrgb instead of pnmraw,
> but that just took longer. Is there any way for gs to
> more quickly (i.e., less slowly) run this ps-->gif conversion
> with a transparent background?

Well my first thought is that you haven't really identified GS as the 
bottleneck here. I personally would invoke GS from the shell, using the 
command given, and time how long it takes. I suspect this may show that 
GS is doing its bit quite quickly.

I'd also ned to see the 'and-some-other-stuff' parts of the command 
line, since the bits you've quoted are really almost entirely irrelevant 
:-) Only the DEVICE switch from there is useful....

My suspicion would be that assembling an animated GIF from 100 PNM files 
is the slow bit, especially if ImageMagick is doing any kind of 
filtering on the data.

A quick test on my (5 year old) PC here ran your v2 test in 18 seconds, 
producing 100 pages, each of which is 1.5Mb in size. So I'm seeing data 
produced by GS at ~7MB/second, which isn't bad, though it is slower than 
I woudld expect. Of course assembling the animated GIF means that 
ImageMagick has to read 150MB of data and presumably remove the white 
space.

Two things spring immediatley to mind:

1) Reduce the resolution. I can't recall what the default resolution for 
pnmraw is, and you command line doesn't tell me what's being used.

2) Reduce the page size. There's a *lot* of white space on the page, 
even when you consider the total drawing rather than each individual 
page. You don't seem to be setting the page size anywhere, but relying 
on the default. Moving the drawing so that the lower and left parts of 
the drawing are at x=0 and y=0, and then reducing the media size so that 
the media is just large enough to contain the drawing woudl reduce the 
amount of white space. This would reduce the amount of data GS produces 
and also (of course) the amount of data ImageMagick has to process.


On the PostScript front, you should bind your procedures. You clearly 
don't intend to have them change at run-time (which is the reason why 
you wouldn't bind them). Bound procedures run faster, as the interpreter 
doesn't have to lookup and execute the PostScript each time. Doing this 
with your file reduced the execution time from 18 secs to 3 seconds on 
my PC. Your mileage may vary of course.




			Ken

[toc] | [prev] | [next] | [standalone]

#870

ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...
> 
>> The reason I mention all that is because the gif's
>> 5MB, and convert took 6mins to render it from ps
>> on an i7-920 (though only utilizing one core).
> 
> Well it is 100 pages of output, and each page is of
> steadily increasing complexity.

I suppose...just can't quite wrap my head around
anything taking 6mins on an i7.

>>    That's at least partly because I couldn't originally
>> figure out how to get a transparent background.
>> So the first %%Page contains one lineto, the second page
>> contains two, ..., the hundredth/last contains 100 (total 5050).
>> A smaller and faster version using
>>   convert -transparent "#FFFFFF" -delay 0 -loop 0 input.ps output.gif
>> whose input/output is at
>>   http://www.forkosh.com/decorative/decofweek-v2.ps
>>   http://www.forkosh.com/decorative/decofweek-v2.gif
>> works with each %%Page containing only one line (total 100),
>> and the transparent background lets those lines build up.
> 
> Hmm, PostScript doesn't support transparency, not at all. So ImageMagick 
> must be treating the untouched background as transparent, I've no idea 
> how it is doing that.

If I understand (emphasize if), -transparent "#FFFFFF" (r=g=b=FF=255)
renders anything white as transparent. So it's not distinguishing
bg/fg, per se, just white/non-white, and bg happens to be white,
and fg happens never to be white in this case.

> Also, of course, PostScript doesn't output animations, since its 
> intended as a printing langage, so the animated GIF is presumably 
> assembled by ImageMagick. I don't know anything about the application 
> I'm afraid.

Yes, IM does some nifty stuff. And it conveniently interprets
each ps %%Page as a frame. You'd otherwise have to supply it
with a whole separate input file for each frame (100 input files
in this case).

>> But the v2-file's still 350KB and convert takes 31secs,
>> which is still too slow for online world use. ImageMagick
>> convert runs gs for its ps-->gif conversion, driven by a
>> delegates.xml file (in /usr/lib/ImageMagick-6.4.3/config/
>> on my box) containing the line
>>   <delegate decode="ps:color" command="---see below---"/>
>> where command is
>>   gs -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE -dNOPROMPT
>>      -sDEVICE=pnmraw
>>      -and-some-other-stuff
>> Trying to speed it up, I naively tried psrgb instead of pnmraw,
>> but that just took longer. Is there any way for gs to
>> more quickly (i.e., less slowly) run this ps-->gif conversion
>> with a transparent background?
> 
> Well my first thought is that you haven't really identified GS as the 
> bottleneck here. I personally would invoke GS from the shell, using the 
> command given, and time how long it takes. I suspect this may show that 
> GS is doing its bit quite quickly.

Okay, I'll give that a try (later because today's actual workday
begins soon), and see if my times resemble your 18secs reported
below (perhaps scaled for your 5yo PC, though my i7's 2.5yo).

> I'd also ned to see the 'and-some-other-stuff' parts of the command 
> line, since the bits you've quoted are really almost entirely irrelevant 
> :-) Only the DEVICE switch from there is useful....

Well, the complete xml <tag> is (I've only added some newlines and spaces)
  <delegate decode="ps:color" stealth="True"
  command="&quot;gs&quot; -q -dQUIET -dPARANOIDSAFER -dBATCH -dNOPAUSE
  -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=0
  &quot;-sDEVICE=pnmraw&quot; -dTextAlphaBits=%u -dGraphicsAlphaBits=%u
  &quot;-r%s&quot; %s &quot;-sOutputFile=%s&quot;
  &quot;-f%s&quot; &quot; -f%s&quot;"/>
which IM's apparently using as a format string, so it's not entirely
clear what the command looks like when executed. The -r%s, presumably
for -r<X>x<Y>, seems to be followed by an all-alone %s that could
be filled in with pretty much anything IM's little heart desires,
or just filled in with " ".

> My suspicion would be that assembling an animated GIF from 100 PNM files 
> is the slow bit, especially if ImageMagick is doing any kind of 
> filtering on the data.

Hard to tell precisely what IM's doing when. I tried watching it
with "top", but couldn't quite keep track of the stuff it fork()'ed off.
I'll have to put some more effort into that kind of thing.

> A quick test on my (5 year old) PC here ran your v2 test in 18 seconds, 
> producing 100 pages, each of which is 1.5Mb in size. So I'm seeing data 
> produced by GS at ~7MB/second, which isn't bad, though it is slower than 
> I woudld expect. Of course assembling the animated GIF means that 
> ImageMagick has to read 150MB of data and presumably remove the white 
> space.
> 
> Two things spring immediatley to mind:
> 
> 1) Reduce the resolution. I can't recall what the default resolution for 
> pnmraw is, and you command line doesn't tell me what's being used.

Maybe in that all-alone %s. But IM does have switches
   -resample geometry   change the resolution of an image
   -resize geometry     resize the image
that I haven't played with (yet). I'll give them a try and
see what effect they have.

> 2) Reduce the page size. There's a *lot* of white space on the page, 
> even when you consider the total drawing rather than each individual 
> page. You don't seem to be setting the page size anywhere, but relying 
> on the default. Moving the drawing so that the lower and left parts of 
> the drawing are at x=0 and y=0, and then reducing the media size so that 
> the media is just large enough to contain the drawing woudl reduce the 
> amount of white space. This would reduce the amount of data GS produces 
> and also (of course) the amount of data ImageMagick has to process.

Okay, I can put that in as an option. Right now the scale/translate
are meant to center images on letter or a4 paper, which is quite
irrelevant for these animation pages that aren't meant for printing.
(This whole thing's basically a toy that's gotten somewhat out of hand.)

> On the PostScript front, you should bind your procedures. You clearly 
> don't intend to have them change at run-time (which is the reason why 
> you wouldn't bind them). Bound procedures run faster, as the interpreter 
> doesn't have to lookup and execute the PostScript each time. Doing this 
> with your file reduced the execution time from 18 secs to 3 seconds on 
> my PC. Your mileage may vary of course.
>  Ken

That's easy enough. I'll edit it into the emitted text, and see
if it makes any noticeable difference in the overall IM runtime.
18-to-3 is obviously an enormous difference.
Thanks so much for your time and advice.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#873

ken <ken@spamcop.net> wrote:
> john@please.see.sig.for.email.com says...

Okay, I think I've implemented all your suggestions below, and
(just to top-post a scoreboard of all the results) the sequence
of improving file sizes and convert runtimes (on an i7-920) is...
Original
  http://www.forkosh.com/decorative/decofweek.gif
  http://www.forkosh.com/decorative/decofweek.ps
  File size ~5MB, convert time ~6mins.
V2
  http://www.forkosh.com/decorative/decofweek-v2.gif
  http://www.forkosh.com/decorative/decofweek-v2.ps
  File size 350KB, convert time 31secs.
and finally V3 with your suggestions
  http://www.forkosh.com/decorative/decofweek-v3.gif
  http://www.forkosh.com/decorative/decofweek-v3.ps
  File size 194KB, convert time 9.6secs
  (Note: that's with a 4"x4" %%BoundingBox: 0 0 288 288)
In all cases the convert command was,
  convert -transparent "#FFFFFF" -delay 0 -loop 0 input.ps output.gif

Besides downloading those .ps links, I put the cgi online (the
C source will eventually be gpl'ed) at
  http://www.forkosh.com/cgi-bin/stringart.cgi
The %%Title of each .ps file is the ?query_string that generated it.
For example,
  .../stringart.cgi?ps&animation=1&huea=0&hueb=360&hue1=999&hue2=999&
  linewidthpt2=4&papersize=4&papermargin=0
should make your browser prompt you to save stringart.ps,
identical to the decofweek-v3.ps file above.
   If you remove those first two "ps&animation=1&" attributes,
your browser should display the corresponding gif, i.e.,
stringart.cgi will run convert for you and just emit the gif.
In this case, removing "animation=1", just emits
the "last frame", the completed design containing all lines.
(Running convert for animations is disabled due to resources
required, so you can only request the ps file.)

> My suspicion would be that assembling an animated GIF from 100 PNM files 
> is the slow bit, especially if ImageMagick is doing any kind of 
> filtering on the data.
>    A quick test on my (5 year old) PC here ran your v2 test in 18 seconds, 
> producing 100 pages, each of which is 1.5Mb in size. So I'm seeing data 
> produced by GS at ~7MB/second, which isn't bad, though it is slower than 
> I woudld expect. Of course assembling the animated GIF means that 
> ImageMagick has to read 150MB of data and presumably remove the white 
> space.

I tried (on the i7-920)
   gs -q -dQUIET -dBATCH -dNOPAUSE -sDEVICE=pnmraw
      -sOutputFile=decofweek.pnm decofweek.ps
which ran in ~4secs and produced one 144MB output file.
Then convert -switches decofweek.pnm decofweek.gif
still took ~6mins, so you're right that's the "slow bit".

> Two things spring immediatley to mind:
> 
> 1) Reduce the resolution. I can't recall what the default resolution for 
> pnmraw is, and you command line doesn't tell me what's being used.

Still haven't played with the convert -switches mentioned in
the preceding followup to your same post. (I don't think there's
any additional way to affect resolution on "the postscript front"
besides your suggestions below which are all implemented now.)

> 2) Reduce the page size. There's a *lot* of white space on the page, 
> even when you consider the total drawing rather than each individual 
> page. You don't seem to be setting the page size anywhere, but relying 
> on the default. Moving the drawing so that the lower and left parts of 
> the drawing are at x=0 and y=0, and then reducing the media size so that 
> the media is just large enough to contain the drawing woudl reduce the 
> amount of white space. This would reduce the amount of data GS produces 
> and also (of course) the amount of data ImageMagick has to process.

I believe that's all done in decofweek-v3 (the "papersize" and
"papermargin" attributes in the example query_string above), and
probably accounts for all the v2-to-v3 improvement cited above.

> On the PostScript front, you should bind your procedures. You clearly 
> don't intend to have them change at run-time (which is the reason why 
> you wouldn't bind them). Bound procedures run faster, as the interpreter 
> doesn't have to lookup and execute the PostScript each time. Doing this 
> with your file reduced the execution time from 18 secs to 3 seconds on 
> my PC. Your mileage may vary of course.

Did that, too, but I noticed absolutely zero runtime change
(~4secs before, ~4secs after). Go figure.
Thanks so much, Ken,
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web