[dvipdfmx] XObject form bounding box problem

[Petr Krajník]

> 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:
\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 (xobj issued x) (xobj issued y) cm 1 w 0 0 m 
10 10 l S}
or
\special{pdf:code 1 w (xobj issued x) (xobj issued y) m ((xobj issued x 
+ 10) (xobj issued y + 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