[dvipdfmx] XObject form bounding box problem
Petr Krajník
petrkrajnik at outlook.cz
Fri Jun 21 09:24:02 CEST 2019
I forget to set the \hoffset and \voffset in my example. As this is
essetntial to show the problem I decided to repost it. Also I refined
the other examples.
I apologize for that.
Petr
> The /BBox and /Matrix entries of the XObject are correct. The BBox coordinates
> correspond to the location where the `bxobj' special was issued.
>
> The BBox in local coordinates of the XObject come into play when the XObject
> is referenced (pdf:uxobj special) elsewhere on the page. BBox local coordinates
> are obtained by
>
> [ llx* lly* 1 ] = [ llx lly 1 ] . [ Matrix ]
> [ urx* ury* 1 ] = [ urx ury 1 ] . [ Matrix ]
>
> where the elements of `Matrix' are taken from the
> /Matrix [ <a> <b> <c> <d> <tx> <ty> ] entry in the XObject according to
>
> <a> <b> 0
> <c> <d> 0
> <tx> <ty> 1
Technically the BBox and Matrix are correct, that's right. What I don't
understand is why we complicate that with calculating in the coordinates
where the xobject was issued.
If we use
\sepacial{pdf:bxobj @test width 100pt height 10pt depth 0pt}
I would expect /BBox[0 0 9.966 9.966] and /Matrix [1 0 0 1 0 0]. This is
the way how pdftex/luatex it does.
> In terms of local coordinates, the coordinate [0 0] corresponds to the
> reference point of the XObject to be inserted.
That is not true. And this is the problem that I describe. You or TeX
need to insert another cm matrix to the stream as every xobject
coordinates must be shifted by the location where the object is issued.
Example of simple code (plain tex/xetex):
\hoffset=100pt % These values are assigned to llx and lly
\voffset=3\baselineskip
\special{dvipdfmx:config z 0}% To make readable PDF
\special{pdf:bxobj @test width 10pt height 10pt depth 0pt}
\special{pdf:code 1 w 0 0 m 10 10 l S}
\special{pdf:exobj}
\def\test{\special{pdf:uxobj @test}}\test
\bye
This code does not work. If the [0 0] were on the right place it would
work. The coordinates of pdf:code are object issue distance away so that
we dont hit the bounding box with coordinates in the stream.
You can change the pdf:code to pdf:content and that insert cm matrix to
the stream that move the [0 0] to the right point. This adds a
additional matrix an q/Q code that wouldn't be needed. We only jump back
and forth with additional code!
So the right pdf:code would be (this is only pseudocode):
\special{pdf:code 1 0 0 1 99.626(hoffset) -35.866(-\voffset) cm cm 1 w 0
0 m 10 10 l S}
or
\special{pdf:code 1 w (\hoffset) (\voffset) m (\hoffset + 10) (-\voffset
+ 10) l S}
Nothing of that would be needed if we do not calculated issued
coordinates in the bbox and matrix.
> XObjects are supposed to be self-contained encapsulated entities that store
> typeset content for later replay. Thus, it is quite natural to also store the
> text colour that was effective upon creation of the XObject. Thus,
> colour injection is not possible when referencing an XObject. This is
> the same behaviour as with LaTeX \savebox+\usebox.
At this point you are right. I misunderstood the pdf reference manual.
XObjects are cached (that's the benefit of using that), so injection of
whatever is nonsense. Thank you for the clarification.
Petr
More information about the dvipdfmx
mailing list