good. I am on way to do that. Another issue is that I am implementing a primitive requrested by Cho, to grab the BBox of an included pdf. Syntax: \pdfximagebbox\pdflastximage 1 => print BBox1 ... \pdfximagebbox\pdflastximage 4 => print BBox4 A question here: what should be printed? something like 10pt, or 10sp, or 10bp, or just 10? 10pt seems to be easy and also consistent with syntax of similar primitives, however the BBox of pdf is often in bp, so instead of 10bp we would get 10.03749pt. Is this a problem? Thanh On Thu, Sep 15, 2005 at 11:52:03AM +0200, Pawel Jackowski wrote:
Hi,
at the moment \pdfforcepagebox overrides the setting given by \pdfximage. Isn't this a little bit unlogical that the global setting overrides the setting in individual use of \pdfximage?
indeed.
I suggest to change \pdfforcepagebox to \pdfpagebox as a global variable indicating which pagebox shoud be used in case no pagebox specification is given with a \pdfximage. used.
makes sense
good idea. -- Pawe/l Jackowski P.Jackowski@gust.org.pl
Thanh Han The wrote:
good. I am on way to do that.
Another issue is that I am implementing a primitive requrested by Cho, to grab the BBox of an included pdf.
Syntax:
\pdfximagebbox\pdflastximage 1 => print BBox1 ... \pdfximagebbox\pdflastximage 4 => print BBox4
A question here: what should be printed? something like 10pt, or 10sp, or 10bp, or just 10? 10pt seems to be easy and also consistent with syntax of similar primitives, however the BBox of pdf is often in bp, so instead of 10bp we would get 10.03749pt. Is this a problem?
either n.m. pt or n.m (without unit being base points) outputing something n.m bp is rather untexie 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 -----------------------------------------------------------------
Hello, On Thu, Sep 15, 2005 at 04:31:18AM -0700, Thanh Han The wrote:
Another issue is that I am implementing a primitive requrested by Cho, to grab the BBox of an included pdf.
What's the purpose? The knowledge of width and height is important (graphicx, pdfpages, ...). By putting \pdfximage into a box these values are easily available (see pdftex.def). I would be interested, in which case the exact offset must be known.
Syntax:
\pdfximagebbox\pdflastximage 1 => print BBox1 ... \pdfximagebbox\pdflastximage 4 => print BBox4
A question here: what should be printed? something like 10pt, or 10sp, or 10bp, or just 10? 10pt seems to be easy and also consistent with syntax of similar primitives, however the BBox of pdf is often in bp, so instead of 10bp we would get 10.03749pt. Is this a problem?
What about returning a dimen like \wd, \ht, and \dp that
take the box number as argument?
Next issues:
* I assume the box (media, crop, ...) is choosen by
the previous \pdfximage?
* What is "1" until "4"?
* It is the first until fourth component
of the box retangle, given in the pdf file?
* The pdf spec says that the box typically has the form:
[ ll_x ll_y ur_x ur_y ]
(PDF spec for 1.6, section "3.8.4 Rectangle")
But there is a note that says that any two diagonally
opposite corners are acceptable and that applications that
process PDF should be prepared to normalize such rectangles.
The question is now, does pdfTeX normalize the rectangle?
This has the advantage that the numbers "1" until "4" also
have the symbolic meaning "ll_x" until "ur_y".
Yours sincerely
Heiko
Heiko Oberdiek wrote:
Hello,
On Thu, Sep 15, 2005 at 04:31:18AM -0700, Thanh Han The wrote:
Another issue is that I am implementing a primitive requrested by Cho, to grab the BBox of an included pdf.
What's the purpose? The knowledge of width and height is important (graphicx, pdfpages, ...). By putting \pdfximage into a box these values are easily available (see pdftex.def). I would be interested, in which case the exact offset must be known.
there are users who want to use pdftex to produce dvi code and use dvipdfmx to produce the pdf; now that pdftex is the main tex engine, we need to address both audiences. (btw, this feature should therefore also work when pdfoutput=0) usually the numbers returned are directly passed into the special that dvipdfmx uses for inclusion 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 Thu, Sep 15, 2005 at 03:32:41PM +0200, Hans Hagen wrote:
Heiko Oberdiek wrote:
Hello,
On Thu, Sep 15, 2005 at 04:31:18AM -0700, Thanh Han The wrote:
Another issue is that I am implementing a primitive requrested by Cho, to grab the BBox of an included pdf.
What's the purpose? The knowledge of width and height is important (graphicx, pdfpages, ...). By putting \pdfximage into a box these values are easily available (see pdftex.def). I would be interested, in which case the exact offset must be known.
there are users who want to use pdftex to produce dvi code and use dvipdfmx to produce the pdf; now that pdftex is the main tex engine, we need to address both audiences.
dvi users need to know the width and height of the graphics that TeX can reserve the needed place.
(btw, this feature should therefore also work when pdfoutput=0)
Ah, interesting.
usually the numbers returned are directly passed into the special that dvipdfmx uses for inclusion
* dvipdfm: CTAN:dviware/dvipdfm/dvipdfm-0.13.2c.pdf
Section "8.1 Epdf" explains the epdf special that can
embed the first page of a pdf file, but I didn't found
any need of bounding box information.
* dvipdfmx: CTAN:dviware/dvipdfmx/README
There is a section "6. DVI Specials" and
"6.2. Additions to Dvipdfm's pdf: Special",
but unhappily both sections are empty.
Is there a better source of information?
Yours sincerely
Heiko
On Fri, Sep 16, 2005 at 01:42:29AM +0200, Heiko Oberdiek wrote:
On Thu, Sep 15, 2005 at 03:32:41PM +0200, Hans Hagen wrote:
usually the numbers returned are directly passed into the special that dvipdfmx uses for inclusion
* dvipdfmx: CTAN:dviware/dvipdfmx/README There is a section "6. DVI Specials" and "6.2. Additions to Dvipdfm's pdf: Special", but unhappily both sections are empty. Is there a better source of information?
I found by accident in spc_pdfm.c:
/* Grab page content as follows:
*
* Reference point = (x_user, y_user)
*
* Case 1. \special{pdf:bxobj @obj width WD height HT depth DP}
*
* Grab the box with the lower-left corner (x_user, y_user-DP)
* and the upper right corner (x_user+WD, y_user+HT).
*
* Case 2. \special{pdf:bxobj @obj bbox LLX LLY URX, URY}
*
* Grab the box with the lower-left corner (x_user+LLX, y_user+LLY)
* and the upper right corner (x_user+URX, y_user+URY).
*
* Note that scale, xscale, yscale, xoffset, yoffset options are ignored.
*/
Thus normalization is a good idea.
Yours sincerely
Heiko
Heiko Oberdiek wrote:
* dvipdfm: CTAN:dviware/dvipdfm/dvipdfm-0.13.2c.pdf Section "8.1 Epdf" explains the epdf special that can embed the first page of a pdf file, but I didn't found any need of bounding box information.
dvipdfm is kind of obsolete and replaced by dvipdfmx
* dvipdfmx: CTAN:dviware/dvipdfmx/README There is a section "6. DVI Specials" and "6.2. Additions to Dvipdfm's pdf: Special", but unhappily both sections are empty. Is there a better source of information?
the source code -) Also, there is a nice presentation by Chof that mentions a lot. 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-09-15 14:57:59 +0200, Heiko Oberdiek wrote:
* The pdf spec says that the box typically has the form: [ ll_x ll_y ur_x ur_y ] (PDF spec for 1.6, section "3.8.4 Rectangle") But there is a note that says that any two diagonally opposite corners are acceptable and that applications that process PDF should be prepared to normalize such rectangles. The question is now, does pdfTeX normalize the rectangle?
AFAIK it doesn't, and I've yet to see a PDF in the wild that has a rectangle with [ ul_x ul_y lr_x lr_y ] . I doubt that gs & xpdf can handle this... Best Martin -- http://www.tm.oneiros.de
participants (4)
-
Hans Hagen -
Heiko Oberdiek -
Martin Schröder -
Thanh Han The