I can use Acrobat Exchange to rotate all the pages and
then everthing is great but that isn't an option for the
automated system I need to set up.
Hopefully, there is some parameter I can tweak in distiller
to do this final page rotation but I can't find it and
Adobe help wasn't telling me.
Any clues?
Good luck,
Bruce
I have never been able to get around it (except by the method you
mentioned, but, if everyone is to use Exchange, then we don't need
Distiller (see why I said it turns out to be virtually useless)).
We've wasted thousands of dollars on useless Distiller Mac/Unix/Pc
licensees in our company.
John Gianni
Cadence Design Systems Inc.
I had the same problem. The solution was to hand edit the source PostScript
file to unrotate the image and to adjust the coordinates to bring the image
back into the viewable area. From memory I believe the source PostScript
had the following lines close to the start of the file:
90 rotate
0.5 inch -10.5 inch translate
I deleted the line "90 rotate" and edited the translate line to become:
0.5 inch 0.5 inch translate
The problem then was that the paper size produced by Distiller was the
wrong orientation. In my case I used a batch file to create a single pdf
from multiple .ps files (as documented by Adobe). It contained the following
line after the initial batch file comment lines:
<</PageSize [1008 792]>> setpagedevice
This forced Distiller to produce an A3 landscape page.
As you can probably guess there is plenty of scope for experimentation...
-- Peter Howe
SGS-THOMSON Microelectronics, Bristol, UK
This must be some kind of bug in Distiller. My own Tumbler utility
<ftp://sumex-aim.stanford.edu/info-mac/gst/grf/tumbler-06d2.hqx> produces
PDF versions of landscaped pages just fine.
Try editing the PDF file. Look for a record that starts with:
/Type /Page
and add a line, somewhere in that record, that says:
/Rotate 90
This will rotate the page to which the record applies, by 90 degrees
clockwise.
Unfortunately, adding characters to a PDF file will mess up the pointers
and checksums, but you may find that Exchange will automatically fix
things when you view the file.
R.
We have the same problem with the electronic distribution of our landscape
reports. PDF supports a /Rotate command with an integer (a multiple of 90)
as an argument. It is possible to distill a PS file and then insert the
/Rotate command after your /MediaBox.
3 0 obj
<<
/Type /Page
/Parent 4 0 R
/MediaBox[0 0 612 792 ]
/Rotate 90
>>
endobj
PDF files contain page objects, and here is the problem. The PDF is read
bottom up. At the bottom of the file is a cross-reference table, which
contains the byte offset of each object in the file. Adding the /Rotate 90
command causes the byte offset in the reference table pertaining to each
object that comes after the object that was changed, to be off by -11.
There is also a byte offset for the cross-reference table after the trailer,
which will be off by -11.
Adding the /Rotate command without adjusting the byte offsets in the xref
table will cause the file to appear damaged when it is opened by the
reader. The reader however, will still open the file, in a now correctly
rotated, landscape mode.
I am currently working on a program that will adjust the byte offsets to
compensate for this problem, and allow the reader to correctly open the file
with no complaints of it being damaged. Time allowing, I should hopefully
have something ready by the end of this month. I hope this information helps!
Ernest Rojem
Document Specialist
Owens-Corning Fiberglas
(419) 248-8829
bizarre statements.
a) if you dont have distiller, you can only create simplistic PDF
document with no automatic links
b) to get landscape pages from Distiller is easy, tell your
application to put out a PageSize setpagedevice command to the PS
file. if your application cant do it, junk the application
c) why did you keep on buying licenses for multiple machines if it
could do what you wanted?
yrs, a happier acrobat user
sebastian rahtz
> Adding the /Rotate command without adjusting the byte offsets in the xref
> table will cause the file to appear damaged when it is opened by the
> reader. The reader however, will still open the file, in a now correctly
> rotated, landscape mode.
>
> I am currently working on a program that will adjust the byte offsets to
> compensate for this problem, and allow the reader to correctly open the file
> with no complaints of it being damaged.
Oh my God! That is a *hideous* hack. Have you read the documentation for
the PDF file format? The PDF document specs make it possible to change an
attribute of an object in the document without updating all of the byte
offsets.
The correct way to do this is spelled out in Chapter 5 of the
documentation with examples in Appendix A. You just need to mark the old
object in the xref table as being free. Add the correction to the end of
the file, add a new xref subsection with the xref entry of your
correction, and then build a new trailer.
The trailer contains a /Size attribute which lists the number of entries
in the old xref tables plus the number of new entries in your subsection.
Followed by a /Root keyword with the obj reference for the Catalog. You
can copy this from the previous trailer. Then give a /Prev keyword with
the byte offset of the old xref table from the beginning of the document.
This can be obtained from the old startxref listing. Finally, you have to
add a new startxref which gives the byte offset of your new xref from the
beginning of the file.
This is the basic method for making an incremental change to a PDF file.
I hope that it helps.
Fred
===================================================================================
Most people believe they are thinking
when they really rearranging their prejudices.
---Edward R. Murrow
===================================================================================