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

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

. bbox of a set of glyphs

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

Contents

  .   bbox of a set of glyphs jodun@mail.com - 2015-04-30 15:05 -0700
    Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-01 07:48 +0100
    Re: .   bbox of a set of glyphs jdaw1 <jdawiseman@gmail.com> - 2015-05-01 01:50 -0700
    Re: .   bbox of a set of glyphs jodun@mail.com - 2015-05-02 06:48 -0700
      Re: .   bbox of a set of glyphs jdaw1 <jdawiseman@gmail.com> - 2015-05-02 14:13 -0700
        Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-04 08:00 +0100
          Re: .   bbox of a set of glyphs jdaw1 <jdawiseman@gmail.com> - 2015-05-08 01:34 -0700
            Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-08 10:44 +0100
              Re: .   bbox of a set of glyphs jdaw1 <jdawiseman@gmail.com> - 2015-05-08 05:06 -0700
            Re: .   bbox of a set of glyphs SaGS <sags5495@gmail.com> - 2015-05-11 01:40 -0700
              Re: .   bbox of a set of glyphs jdaw1 <jdawiseman@gmail.com> - 2015-05-11 02:58 -0700
      Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-04 08:50 +0100
    Re: .   bbox of a set of glyphs jodun@mail.com - 2015-05-04 11:22 -0700
    Re: .   bbox of a set of glyphs jodun@mail.com - 2015-05-07 14:01 -0700
      Re: .   bbox of a set of glyphs luser- -droog <mijoryx@yahoo.com> - 2015-05-07 21:19 -0700
      Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-08 08:21 +0100
      Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-08 12:06 +0100
    Re: .   bbox of a set of glyphs jodun@mail.com - 2015-05-12 07:44 -0700
      Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-12 16:36 +0100
    Re: .   bbox of a set of glyphs jodun@mail.com - 2015-05-14 08:18 -0700
      Re: .   bbox of a set of glyphs ken <ken@spamcop.net> - 2015-05-14 17:31 +0100

Page 1 of 2  [1] 2  Next page →

#2237 — . bbox of a set of glyphs

Hi

In ghostscript (latest) 
I generate a fancy spiraling set of words/banners
of varying scalings, rotations and translations
adjacent (or even intersecting) to each other in one image.

I have no problem doing the above.

But right now I have to resort to postprocessing
with IrfanView to trim the unwanted empty margins of my masterpiece.

Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
sans postprocessing?

I think I need to compute the *overall* bounding box
But if I use the bbox device, I get an utterly wrong answer.

Help
-
baaa

[toc] | [next] | [standalone]

#2238

In article <e960544e-41e2-4c87-bda4-dca56daf7c41@googlegroups.com>, 
jodun@mail.com says...

> I think I need to compute the *overall* bounding box
> But if I use the bbox device, I get an utterly wrong answer.

Then perhaps you should raise a bug report ?
 
> Help

At the very least we're going to need to see an example, the description 
of the problem is too vague.


			Ken

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

#2239

Or make the path, in PostScript compute its bounding box with
    flattenpath pathbbox
then
    << /PageSize [ ... ] >> setpagedevice
and then regenerate the path and paint it.

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

#2243

On Thursday, April 30, 2015 at 6:05:46 PM UTC-4, jo...@mail.com wrote:
> Hi
> 
> In ghostscript (latest) 
> I generate a fancy spiraling set of words/banners
> of varying scalings, rotations and translations
> adjacent (or even intersecting) to each other in one image.
> 
> I have no problem doing the above.
> 
> But right now I have to resort to postprocessing
> with IrfanView to trim the unwanted empty margins of my masterpiece.
> 
> Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
> sans postprocessing?
> 
> I think I need to compute the *overall* bounding box
> But if I use the bbox device, I get an utterly wrong answer.
> 
> Help
> -
> baaa

-------------------------------- code ----------------------

0 setgray

/Times-Bold 111 selectfont 200 444 moveto  (Sun)  show
/Arial 44 selectfont           60 rotate   (Moon) show
2 3 scale
/Courier-Italic 300 selectfont 45 rotate   (Pluto)show
-----------------------------end code -----------------

Now, how can I get the overall/cumulative  bounding box ?
and  how to clip the margins out ?

--
baaa

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

#2244

> 0 setgray
> 
> /Times-Bold 111 selectfont 200 444 moveto  (Sun)  show
> /Arial 44 selectfont           60 rotate   (Moon) show
> 2 3 scale
> /Courier-Italic 300 selectfont 45 rotate   (Pluto)show
> -----------------------------end code -----------------
> 
> Now, how can I get the overall/cumulative  bounding box ?
> and  how to clip the margins out ?
> 
> --
> baaa


(The below untested. Good luck!)

/Matrix1 matrix currentmatrix def
60 rotate
/Matrix2 matrix currentmatrix def
2 3 scale  45 rotate
/Matrix3 matrix currentmatrix def

/Times-Bold     111 selectfont Matrix1 setmatrix 200 444 moveto (Sun)  true charpath
/Arial           44 selectfont Matrix2 setmatrix 200 444 moveto (Moon) true charpath
/Courier-Italic 300 selectfont Matrix2 setmatrix 200 444 moveto (Pluto) true charpath
Matrix1 setmatrix flattenpath bathbbox

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

#2245

In article <9ce0b2cf-f75e-47f1-9108-eb05413e3ca6@googlegroups.com>, 
jdawiseman@gmail.com says...

> (The below untested. Good luck!)
> 
> /Matrix1 matrix currentmatrix def
> 60 rotate
> /Matrix2 matrix currentmatrix def
> 2 3 scale  45 rotate
> /Matrix3 matrix currentmatrix def
> 
> /Times-Bold     111 selectfont Matrix1 setmatrix 200 444 moveto (Sun)  true charpath
> /Arial           44 selectfont Matrix2 setmatrix 200 444 moveto (Moon) true charpath
> /Courier-Italic 300 selectfont Matrix2 setmatrix 200 444 moveto (Pluto) true charpath
> Matrix1 setmatrix flattenpath bathbbox

Should be pathbbox there, though I like the idea of a bath bbox :-)


			Ken

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

#2251

> Should be pathbbox there, though I like the idea of a bath bbox :-)

Oops. Sorry.



FYI, there's an extra problem with pathbbox: it uses the control points of curves, not the curves themselves. So if the path has curves, its box is reported as being bigger than it should be. This can be exacerbated by rotation. 

Solution: in 
http://www.jdawiseman.com/papers/placemat/placemat.ps 
is defined a routine PathBBox (note capitalisation) that differentiates curves, finds turning points, and from them computes the actual box. 

Also see
https://groups.google.com/forum/#!topic/comp.lang.postscript/oYHVxaMmqjk 
which prompted the writing of PathBBox

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

#2252

In article <70749a71-f37e-414b-9848-51285c1c290f@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> > Should be pathbbox there, though I like the idea of a bath bbox :-)
> 
> Oops. Sorry.
> 
> 
> 
> FYI, there's an extra problem with pathbbox: it uses the control points of curves, not the curves themselves. So if the path has curves, its box is reported as being bigger than it should be. This can be exacerbated by rotation. 

Good point, and that's almost certainly what's causing the differences 
in the bbox calculation.

The GS bbox device does calculate the extents of the paths, which is why 
its more accurate I suspect. Note that mitres can also give similar 
errors, and this too can vary considerably with the resolution.

One of the GS scripts, possibly ps2eps or ps2epsi, used to work by 
rendering to a low resolution bitmap and counting the pixels to find the 
boundaries, which is where this problem (with text as well) surfaced 
originally, and is why that script was altered to use the bbox device.

				Ken

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

#2254

> The GS bbox device does calculate the extents of the paths, which is why 
> its more accurate I suspect. Note that mitres can also give similar 
> errors, and this too can vary considerably with the resolution.

Indeed, in general, the bounding box of a path will be smaller than the bounding box of a path stroked with non-zero width. The extent of the error will be affected by the values of currentlinewidth, currentlinejoin and currentmiterlimit. 

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

#2255

On Friday, May 8, 2015 at 11:34:44 AM UTC+3, jdaw1 wrote:
> ...
> FYI, there's an extra problem with pathbbox: it uses the control points
> of curves, not the curves themselves. So if the path has curves, its
> box is reported as being bigger than it should be. This can be
> exacerbated by rotation.
> ...

True, and that's why you will usually do a "flattenpath" before "pathbbox". And since the path is automatically flattened anyway before a "stroke"/"fill"/etc the result should be accurate enough.

This use case is explained in the PS Reference Manual under "pathbbox" (with a reference from "flattenpath" too), and also used near the end of section 5.4 "Glyph Metric Information". I remember the PS Cookbook also explains this (but I do not have it at hand to check).

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

#2256

> I remember the PS Cookbook also explains this (but I do not have it at hand to check).

It does, on page 159. 

> The flattenpath operator replaces any curveto 
> segments in the path with sequences of straight lines so 
> that the pathbbox operator will return a bounding box 
> that fits the path as closely as possible (otherwise the 
> control points for the curves are included in the 
> bounding box computation and these almost always lie 
> off of the path outline).

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

#2246

In article <fb3c69b4-2c5a-404a-acfa-dbf5a3e25765@googlegroups.com>, 
jodun@mail.com says...

> > I think I need to compute the *overall* bounding box
> > But if I use the bbox device, I get an utterly wrong answer.
> > 
> > Help

Well, you still haven't opened a bug report.....

Assuming the file below is an example of the sort of problem you are 
seeing, the problem is that the bbox device is limited (clipped) by the 
initial page. So if your output extends off the page, it will be clipped 
to it.

> -------------------------------- code ----------------------
> 
> 0 setgray
> 
> /Times-Bold 111 selectfont 200 444 moveto  (Sun)  show
> /Arial 44 selectfont           60 rotate   (Moon) show
> 2 3 scale
> /Courier-Italic 300 selectfont 45 rotate   (Pluto)show
> -----------------------------end code -----------------
> 
> Now, how can I get the overall/cumulative  bounding box ?
> and  how to clip the margins out ?


The Ghostscript bbox device (which is clipped to the page) says that the 
BBOX is 0 441 439 1301.

The code supplied by jdaw1, again using Ghostscript, comes out at -404 
398 383 1214, Acrobat Distiller says -420 396 385 1214 (Bear in mind the 
fonts used are probably slightly different since they are not embedded).

I have no idea which is correct, I presume you know. However, if you 
accept the fact that the bbox device clips to the page, then these are 
all in reasonably close agreement, I certainly don't see the bbox device 
answer as 'utterly wrong'.

So, I then modified the iput file to move the entire conetnt onto the 
page (and made the page size large enogh to hold the content. I did ths 
by modifying your code:

%!
<</PageSize [4000 4000]>> setpagedevice
1000 0 translate

/Times-Bold 111 selectfont 200 444 moveto  (Sun)  show
/Arial 44 selectfont           60 rotate   (Moon) show
2 3 scale
/Courier-Italic 300 selectfont 45 rotate   (Pluto)show
showpage

Running this through the bbox device gives me:

%%BoundingBox: 127 441 1439 2575
%%HiResBoundingBox: 127.964809 441.897737 1438.657550 2574.422078

So, the modified file has its lower left at 127,441 and its upper right 
at 1439,2575.

As to clipping out the margins, you use 'rectclip'. Howeever, what I 
assume you *actually* mean is 'how do I draw this so it fills the page 
with no white space'. In which case the answer is that you set the 
PageSize to be the width and height, and translate the bottom left 
corner of the content to 0,0.

So I modified your original file thus:

%!
<</PageSize [1312 2134]>> setpagedevice
873 -441 translate

/Times-Bold 111 selectfont 200 444 moveto  (Sun)  show
/Arial 44 selectfont           60 rotate   (Moon) show
2 3 scale
/Courier-Italic 300 selectfont 45 rotate   (Pluto)show
showpage

So how did I arrive at those figures ? Easy, the width is given by urx - 
llx = 1439 - 127 = 1312. Heiht is given by ury - lly = 2575 - 441 = 
2134.

We know that when we offset the content by x=1000, y=0 that the content 
started at llx = 127, lly = 441. So we need to translate the content by 
that amount. 1000 - 127 = 873, and 0 -441 = -441.
 

If I run this through Ghostscript then the result is ver close to a 
tight clip to the text. Differences in resolution, and rounding errors, 
will mean that there are always likely to be a few pixels difference. 
You can probably get even closer by using the high resolution bbox. For 
confirmation I ran the file through acrobat distiller and, given the 
caveats about fonts, the result is close to the Ghostscript display.

In any event, the Ghostscript bbox device's result is certainly not 
'utterly wrong', and gives a result better than that proposed by use of 
charpath.


			Ken

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

#2247

On Thursday, April 30, 2015 at 6:05:46 PM UTC-4, jo...@mail.com wrote:
> Hi
> 
> In ghostscript (latest) 
> I generate a fancy spiraling set of words/banners
> of varying scalings, rotations and translations
> adjacent (or even intersecting) to each other in one image.
> 
> I have no problem doing the above.
> 
> But right now I have to resort to postprocessing
> with IrfanView to trim the unwanted empty margins of my masterpiece.
> 
> Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
> sans postprocessing?
> 
> I think I need to compute the *overall* bounding box
> But if I use the bbox device, I get an utterly wrong answer.
> 
> Help
> -
> baaa

Thanks Ken and all
I should have mentioned that I am a perennial newbie.   Worse I, I always bite more than I can chew.  The code example I whipped up above, is a drastically simplified version of the ultimate real code.  

The real code aspires at putting the sample code into a rather tight loop, to start from very miniscule scale (almost zero)
to rather big font sizes.  All on one screen.

Worse still, the whole code should be applied to a database.  So the ambitious
project will give the code a real exercise.


It will take me days to digest the kind replies.  If I do not manage to rewrite the code according to the kind hints put out till now, then you will here more from yours truly.
--
baa

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

#2248

On Thursday, April 30, 2015 at 6:05:46 PM UTC-4, jo...@mail.com wrote:
> Hi
> 
> In ghostscript (latest) 
> I generate a fancy spiraling set of words/banners
> of varying scalings, rotations and translations
> adjacent (or even intersecting) to each other in one image.
> 
> I have no problem doing the above.
> 
> But right now I have to resort to postprocessing
> with IrfanView to trim the unwanted empty margins of my masterpiece.
> 
> Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
> sans postprocessing?
> 
> I think I need to compute the *overall* bounding box
> But if I use the bbox device, I get an utterly wrong answer.
> 
> Help
> -
> baaa

hi  jdaw1
hi  ken

I am back.
After perusing the 2 learnt replies, and even trying to takem from there to complete solutions
I am back to scream for
2 complete solutions.

If I am to venture some humble opinions:

 jdaw1 approach seems to lead to a one-process automatic solution, if only he woul kindly provide a complete code

  Ken's approach - thanks kin for spending a lot of time - may be the more accurate one, but it, in my newbish opinion, 
   a: does not lend it self to a one-process solution
   b: has 4 arbitrary numbers, 4000 4000 1000 0
N.B. As far as I can tell, to get the bbox, we need a separte run
followed by manual arithmtic/trascriptin into a subsequent run.
If, as I ambitiously intend, am gonna process a database of thousand of strings
that manualisation would obviously not do.

The documentation says that the bbox device writes to stderr
For a while I thought the bbox device is the equivalent to pathbbox
but the latter gave me numbers that, after 2 subtractions, gave me a NULL bbox.
That is what i called "utterly wrong"

Not to mention the 2 sets of quad numbers are utterly different.

Again, would it be pushing my luck to ask for more spoon-feeding complete one-process automatic 2 sets of code ?
-
perennially newb
baaa

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

#2249

On Thursday, May 7, 2015 at 4:01:11 PM UTC-5, jo...@mail.com wrote:
> On Thursday, April 30, 2015 at 6:05:46 PM UTC-4, jo...@mail.com wrote:
> > Hi
> > 
> > In ghostscript (latest) 
> > I generate a fancy spiraling set of words/banners
> > of varying scalings, rotations and translations
> > adjacent (or even intersecting) to each other in one image.
> > 
> > I have no problem doing the above.
> > 
> > But right now I have to resort to postprocessing
> > with IrfanView to trim the unwanted empty margins of my masterpiece.
> > 
> > Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
> > sans postprocessing?
> > 
> > I think I need to compute the *overall* bounding box
> > But if I use the bbox device, I get an utterly wrong answer.
> > 
> > Help
> > -
> > baaa
> 
> hi  jdaw1
> hi  ken
> 
> I am back.
> After perusing the 2 learnt replies, and even trying to takem from there to complete solutions
> I am back to scream for
> 2 complete solutions.
> 
> If I am to venture some humble opinions:
> 
>  jdaw1 approach seems to lead to a one-process automatic solution, if only he woul kindly provide a complete code
> 
>   Ken's approach - thanks kin for spending a lot of time - may be the more accurate one, but it, in my newbish opinion, 
>    a: does not lend it self to a one-process solution
>    b: has 4 arbitrary numbers, 4000 4000 1000 0
> N.B. As far as I can tell, to get the bbox, we need a separte run
> followed by manual arithmtic/trascriptin into a subsequent run.
> If, as I ambitiously intend, am gonna process a database of thousand of strings
> that manualisation would obviously not do.
> 
> The documentation says that the bbox device writes to stderr
> For a while I thought the bbox device is the equivalent to pathbbox
> but the latter gave me numbers that, after 2 subtractions, gave me a NULL bbox.
> That is what i called "utterly wrong"
> 
> Not to mention the 2 sets of quad numbers are utterly different.
> 
> Again, would it be pushing my luck to ask for more spoon-feeding complete one-process automatic 2 sets of code ?
> -
> perennially newb
> baaa

There are 2 examples of processing ps files to adjust the bounding box
here:
http://stackoverflow.com/questions/12682621/how-to-adjust-boundingbox-of-an-eps-file

The awk script that I wrote assumes that DSC %%BoundingBox comments are
present. The utility `ps2eps` can be used to add these. Or perhaps a
more elaborate shell script could run `gs -sDEVICE=bbox` if they're
not already there.

HTH

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

#2250

In article <766aec49-0b07-4b3b-ad9d-2e6870d1587c@googlegroups.com>, 
jodun@mail.com says...

>   Ken's approach - thanks kin for spending a lot of time - may be the 
more accurate one, but it, in my newbish opinion, 
>    a: does not lend it self to a one-process solution
>    b: has 4 arbitrary numbers, 4000 4000 1000 0

Only because a portion of your PostScript lies off the media. The 
numbers are indeed arbitrary, but if you can figure out how much off the 
media your code lies, then its possible to insert real numbers. Or 
simply translate the content onto the media before starting.


> The documentation says that the bbox device writes to stderr
> For a while I thought the bbox device is the equivalent to pathbbox
> but the latter gave me numbers that, after 2 subtractions, gave me a NULL bbox.
> That is what i called "utterly wrong"

The 'latter' being pathbbox ? If so I'm confused, because what you said 
was "But if I use the bbox device, I get an utterly wrong answer.".

Also, a degenerate bbox wasn't the result I saw from the bbox device, 
even without translating the content onto the page. Possibly you are 
misusing the co-ordinates, can you give me an example of the numebrs you 
get ?

What I wrote was:

"The Ghostscript bbox device (which is clipped to the page) says that 
the BBOX is 0 441 439 1301."

So that's llx = 0, lly = 441 urx = 439, ury = 1301. Subtraction yields a 
bbox whch has a width of 439 and a height of 860 PostScript units. 
Certainly not NULL.

 
> Not to mention the 2 sets of quad numbers are utterly different.

Which two sets of numbers ?

 
> Again, would it be pushing my luck to ask for more spoon-feeding complete one-process automatic 2 sets of code ?

In general the application generating the PostScript should keep track 
of where it expects marks to be made so the application, generally, 
would keep track of the bbox. In your case you are generating the 
PostScript apparently, so its really up to you to keep an at least 
approximate record of where the marks are.

As far as I understand it at least part of the problem from your POV is 
that you aren't tracking that, not even to the point of ensuring that 
the content is printable.

Remember, PostScript is intended for printing so its quite important to 
make sure all the marks you print lie on the selected media.

So if you aren't going to keep track of the position of the elements on 
the page then its possible you are going to have to do a 2 pass 
approach, yes.

Id the example you've given really representative of the sort of problem 
you intend to tackle ? You intend to process a database of thousands of 
strings, and yet you plan to render them all at unusual angles and 
sizes, and aren't prepared to track the orientation  and positoin of the 
strings, even a little ?

I actually have not spent any real amount of time on ths, otherwise I'd 
look into why the pathbbox solution gives rise to different answers. My 
suspicion is that its because the resolutoin is coarse (probably 72 dpi) 
and so the glyph paths are not being well represented.

			Ken

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

#2253

In article <766aec49-0b07-4b3b-ad9d-2e6870d1587c@googlegroups.com>, 
jodun@mail.com says...

>   Ken's approach - thanks kin for spending a lot of time - may be the 
more accurate one, but it, in my newbish opinion, 
>    a: does not lend it self to a one-process solution
>    b: has 4 arbitrary numbers, 4000 4000 1000 0
> N.B. As far as I can tell, to get the bbox, we need a separte run
> followed by manual arithmtic/trascriptin into a subsequent run.
> If, as I ambitiously intend, am gonna process a database of thousand of strings
> that manualisation would obviously not do.

OK so one of the things you can do is put all your marking code into a 
form (or even a procedure!). Then you can rerun the form as many times 
as you need, potentially under different conditions, to get the result 
you want.

So you could (for example) run the file once with 'show' redefined so 
that it did a 'currentpoint' after each show. That doesn't get you the 
bounding box, but it quickly gives you an approximation to the extents 
of the text.

You can then use that to translate the form completely onto the page 
(and possibly alter the page size) and run the form again to get 
accurate results for the bbox.

Here's your original example, suitably modified to use the charapth 
approach and a procedure for the content rather than a form:

8<----------------------------8<-------------------------8<------------
%!

/Content {
/Times-Bold 111 selectfont 200 444 moveto  (Sun)  show
/Arial 44 selectfont           60 rotate   (Moon) show
2 3 scale
/Courier-Italic 300 selectfont 45 rotate   (Pluto)show
} def

save
/show {true charpath} bind def

matrix currentmatrix
/Content cvx exec
setmatrix

flattenpath pathbbox
5 -1 roll
restore

/ury exch def
/urx exch def
/lly exch def
/llx exch def

(llx ) print llx ==
(lly ) print lly ==
(urx ) print urx ==
(ury ) print ury == flush

<</PageSize [urx llx sub ury lly sub]>> setpagedevice
llx neg lly neg translate

/Content cvx exec
showpage

8<----------------------------8<-------------------------8<------------


Notice the use of flattenpath, that should preclude the inclusion of 
control points in the path before we send it to pathbbox. It does, 
however, convert true curves to a flattened approximatoin, so you will 
need to run ths at a reasonable resolution to get correct results.

Observe that if you run this at different resolutions you will get 
slightly different results, due to the difference in device space 
(pathbbox converts the device space representation back into user space, 
so obviously is affected by the user space->Ldevice space mapping, which 
is affected by the resolution).

If I run that through Ghostscript I get a page tightly clipped to the 
extent of the marks. Using the bbox device I get :

%%BoundingBox: 0 0 1290 2126
%%HiResBoundingBox: 0.000000 0.000000 1289.437554 2125.997935

Is that sufficient for your needs ? You shoud note that if you actually 
intend to print ths, you will need to do the exact same translation of 
the origin as done above, immediately after the setpagedevice. Otherwise 
the marking operations will still take place off the page.

If you want a BoundingBox which accounts for that, well you have the 
asnwer already in the box bounds.

I'm assuming, based on your requirement for one pass, that you intend to 
do 'something' with the content and so translating the origin is the 
right thing to do.


			Ken

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

#2260

On Thursday, April 30, 2015 at 6:05:46 PM UTC-4, jo...@mail.com wrote:
> Hi
> 
> In ghostscript (latest) 
> I generate a fancy spiraling set of words/banners
> of varying scalings, rotations and translations
> adjacent (or even intersecting) to each other in one image.
> 
> I have no problem doing the above.
> 
> But right now I have to resort to postprocessing
> with IrfanView to trim the unwanted empty margins of my masterpiece.
> 
> Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
> sans postprocessing?
> 
> I think I need to compute the *overall* bounding box
> But if I use the bbox device, I get an utterly wrong answer.
> 
> Help
> -
> baaa

am   baaa k

Thanks jdaw1, luser droug,  and of course Ken who took the time to code.

Ken, your code seems to work for fonts,
but for other graphics it is cut off.  Please see my humble  take :
---------------------------------------- start baaa code ----------------------

/Content{
%                    draw a square
0 0 moveto
0 100 lineto
100 100 lineto
100 0 lineto

%                    draw a 'V' shape
0 setlinejoin
 50 0  moveto      0 100 lineto
 50 0  moveto    100 100 lineto  
closepath

}def

%%============================================================= main

%--------------------Ken algorithm, modified by  baaa May 12th, 2015

						save
/show {true charpath} bind def
matrix currentmatrix
			Content
setmatrix
flattenpath pathbbox
5 -1 roll
						restore

/ury exch def
/urx exch def
/lly exch def
/llx exch def
/width  urx llx sub def
/height ury lly sub def

(llx ) print llx ==
(lly ) print lly ==
(urx ) print urx ==
(ury ) print ury ==

/line-width 20 def
(\nline-width )print line-width ==

 line-width setlinewidth

(\nWIDTH   )print width  ==
  (HEIGHT  )print height ==

/wd line-width    width  add def
/ht line-width    height add def

(\nwd   )print wd  ==
  (ht   )print ht  ==



<</PageSize [wd ht]>> setpagedevice
llx neg lly neg translate

line-width  setlinewidth
			Content


%------------------------------  
1 setgray
 stroke

---------------------------------------- end   baaa code ----------------------

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

#2261

In article <5ffcd84c-36e3-4081-9835-dbea724090c7@googlegroups.com>, 
jodun@mail.com says...

> Thanks jdaw1, luser droug,  and of course Ken who took the time to 
code.
> 
> Ken, your code seems to work for fonts,
> but for other graphics it is cut off.  Please see my humble  take :

Its only designed to work for fonts/text, because that's what you posted 
as an example....

All that code does is convert text into paths so that we can do a 
pathbbox on it. For other types of marking operations, different (but 
related) approaches are required.

For example, fill and rectfill could be redefined to simply take the 
bbox of their respective paths, and then execute a newpath. Likewise 
stroke and rectstroke. Images require calculation based on the declared 
width and height, the image matrix and teh current CTM, and so on. If 
you want a fully general approach then there's a lot of work still to 
do.

At all times you need to respect the current clip, which the code above 
doesn't do for text either, note. You would also need to redefine the 
other 9 members of the show family of operators.

If you are going to draw off the media, then you don't have a lot of 
choice about redefining the operators in order to find out the extent of 
the content. This is because in order to find the true, accurate, extent 
we need to convert into device space, and device space, unlike user 
space, is limited to 'real' co-ordinates. THat is, you can't draw off 
the page.

If you can arrange for all your content to be drawn on the page, then 
you can simply use the bbox debice in Ghostscript. If you are going to 
draw all over the place, and not track it yourself, then you need to 
write a PostScript program to do it instead. Its possible, but its not 
trivial.


				Ken

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

#2265

On Thursday, April 30, 2015 at 6:05:46 PM UTC-4, jo...@mail.com wrote:
> Hi
> 
> In ghostscript (latest) 
> I generate a fancy spiraling set of words/banners
> of varying scalings, rotations and translations
> adjacent (or even intersecting) to each other in one image.
> 
> I have no problem doing the above.
> 
> But right now I have to resort to postprocessing
> with IrfanView to trim the unwanted empty margins of my masterpiece.
> 
> Wouldn't be prettier if I could do the whole margin trimming with ghostscript, 
> sans postprocessing?
> 
> I think I need to compute the *overall* bounding box
> But if I use the bbox device, I get an utterly wrong answer.
> 
> Help
> -
> baaa

am baaa k

 ancillary problem :

How to control the bbox ?

Say the input is a database that contains, for simplicity,
just 4 strings, of any number of glyphs per string,  between 1 and 30 :

sun
moon
pluto
.

(Yes
period
full stop
or just any single letter)

The output should be a 2x2 contact sheet.
All four images , should have the exactsame  dimensions
say  1000 x 1000 pixels

How to produce those dimensions-identical 4 images
a- preserving aspect ratio, padding one dimension with blanks
b- not preserving aspect ratio, no padding

/Times-Roman  x selectfont
what should   x be ?

If we scale, what scales ?

--
baaa

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web