[ pdftex-Bugs-303 ] bug in paper metrics?
Bugs item #303, was opened at 2005-03-02 13:30 You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106 Category: None
Group: v1.21a Status: Closed Resolution: Rejected Priority: 5 Submitted By: Wolfgang Glitzner (wolfgang_gg) Assigned to: Nobody (None) Summary: bug in paper metrics?
Initial Comment: Hello there, Texies. Is there a bug in the paper metrics of pdftex or in an involved package? Or just only in the acrobat reader? I produce a pdf doc with pdftex. In particular I use \documentclass[twoside,a5paper]{book} . . . \setlength{\topmargin}{-2.04mm} \setlength{\textheight}{140.15mm} \setlength{\textwidth}{99.1mm} \setlength{\oddsidemargin}{-8.88mm} \setlength{\evensidemargin}{7.63mm} . . . The Check produces: 1) a dump of \the\paperwidth in the logfile gives 421.10078pt, which is 147.999999999mm. 2) the document properties in the acrobat reader displays 148 x 210 mm 3) invoking printing on my canon i450 opens a window in which the field preview tells Paper: 209.97 x 296.7 mm (I have DINA4 mounted, so far, so good) Document: 147.8 x 209.9 mm 4) DINA5 has exactly 210.22 x 148.65 mm 5) DINA4 has exactly 297.30 x 210.22 mm What width my document really has? 148mm or 147,8mm or 148,65mm ?? There is physically only one! And what I assumed and need is a width of 148,65mm. How to apply? Moreover, gluing 2 pages of my doc together with the pdfpages package works fine. 2 DINA5 onto 1 DINA4. In particular I use \documentclass[twoside,a4paper]{book} However, because a DINA5-page misses approx. 0.65mm, some additional adaption is necessary. However, pdfpages applies a parameter for that action. good luck. The Check produces: 1) a dump of \the\paperheight in the logfile gives 421.10078pt, which is 147.999999999mm. 2) the document properties in the acrobat reader displays 297 x 210mm 3) invoking printing on my canon i450 opens a window in which the field preview tells Paper 209.9 x 296.7mm Document 296.7 x 209.9mm General question: IS THE PAPER-metric FOR DINA5 AND DINA4 CORRECT IN THE APPROPRIATE PACKAGE? Regards Wolfgang Glitzner@gmx.de n.b. 1a) A logged metric of pdfpages compilation which keeps the DINA5 is: 421.10124pt x 597.50829pt which is 148.00015991mm x 210.0001462mm. 1b) A logged metric of pdfpages compilation which keeps the DINA4 is: 597.50787pt x 845.04684pt which is 209.9999986mm x 296.9999963mm 2) Some conversions: 72,27 point (amerikanische) sind 1 inch -- exakt! 1 inch sind 25,4 mm -- exakt! 72,27 point/ 25,4 mm = 2,845 point/mm oder 0,3513 mm/point. dots sind nicht points und schon gar nicht pixel. ----------------------------------------------------------------------
Comment By: Martin Schröder (oneiros) Date: 2005-03-02 14:46
Message: Logged In: YES user_id=421 \usepackage{geometry} ---------------------------------------------------------------------- Comment By: Taco Hoekwater (taco) Date: 2005-03-02 14:39 Message: Logged In: YES user_id=1608 This is a 'bug' in article.cls, not pdftex. I suggest closing this tracker item. ---------------------------------------------------------------------- You can respond by visiting: http://sarovar.org/tracker/?func=detail&atid=493&aid=303&group_id=106
Recent versions of illustrator don't provide a cropbox but set the trip and artbox instead; I think that it makes sense, when no box spec is given to pdftex, the fallback scheme should be: cropbox trimbox artbox mediabox instead of cropbox mediabox (interesting how willing adobe is to break compatible behaviour, probably because they use version info inthe graphics to adapt their progs behaviour to) discussions with publishers have learned me that it's impossible to tell designers what boxes are needed because they have no clue (i.e. dtp apps just let you add such a box, some dtp program slook into the file and determine the boundary [dangerous imo], or adding a box is so obscured that it is not done]; so i think we should play safe and not expect perfect graphics -) [this apart from wrong boxes, but we cannot catch that] Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On 2005-03-03 15:22:02 +0100, Hans Hagen wrote:
Recent versions of illustrator don't provide a cropbox but set the trip and artbox instead;
I think that it makes sense, when no box spec is given to pdftex, the fallback scheme should be:
cropbox trimbox artbox mediabox
instead of
cropbox mediabox
(interesting how willing adobe is to break compatible behaviour, probably because they use version info inthe graphics to adapt their progs behaviour to)
No.
The crop box defines the region to which the contents of the page
are to be clipped (cropped) when displayed or printed. Unlike the
other boxes, the crop box has no defined meaning in terms of
physical page geometry or intended use; it merely imposes
clipping on the page contents. However, in the absence of
additional information (such as imposition instructions specified
in a JDF or PJTF job ticket), the crop box determines how the
pages contents are to be positioned on the output medium. The
default value is the pages media box.
</quote>
Notice the last sentence.
Best regards
Martin
--
Martin Schröder, ms@artcom-gmbh.de
ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany
Voice +49 421 20419-44 / Fax +49 421 20419-10
http://www.artcom-gmbh.de
Martin Schröder wrote:
^^
The crop box defines the region to which the contents of the page are to be clipped (cropped) when displayed or printed. Unlike the other boxes, the crop box has no defined meaning in terms of physical page geometry or intended use; it merely imposes clipping on the page contents. However, in the absence of additional information (such as imposition instructions specified in a JDF or PJTF job ticket), the crop box determines how the pages contents are to be positioned on the output medium. The default value is the pages media box. </quote>
Notice the last sentence.
the problem is that "in the beginning of pdf" there were only the mediabox and the cropbox; so, having better defined specs is fine, but we do have to deal with older graphics, and the main thing i have in mind is strategies, so, either we implement something in pdftex, or we need access to the info so that we can implement strategies \pdfgetimagebox artbox|trimbox|cropbox|... {filename} \pdflastimagellx \pdflastimagelly \pdflastimageurx \pdflastimageury (zero when not present) btw, currently a test \setbox0\hbox{\pdfximage \pdfimagepagenumber ArtBox{...}} results in an inclusion; is there a reason why unreferences images are included? i think that even \setbox0\hbox{\pdfximage \pdfimagepagenumber ArtBox{...}\pdfrefximage\pdflastximage} should not lead to an inclusion unless box 0 is flushed ps. ghostscript is unaware of other than media/cropboxes, and artbox and such get lost in conversion; i already filed this as a bug it's a pitty that this kind of stuff was not already sorted out in the pdf 1.1 times Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (3)
-
Hans Hagen -
Martin Schröder -
noreply＠sarovar.org