[DVIPDFMx] New specials and PGF version 2.00 support
Jin-Hwan Cho
chofchof at ktug.or.kr
Sat Jun 7 03:43:48 KST 2008
On Jun 7, 2008, at 3:12 AM, Matthias Franz wrote:
> On Thu, Jun 05, 2008 at 04:18:45PM +0900, Jin-Hwan Cho wrote:
>> To do this, new DVI specials were required:
>
> Just one question:
>
> Is there a special corresponding to pdftex's \pdfliteral?
1. \special{pdf:content ... }
This special came from the original DVIPDFM. It generates "q 1 0 0 1
cur_x cur_y cm ... Q".
Therefore, we can use the relative coordinate inside this special.
But, it does not support
begin ... end environment. To do this, one dirty trick is to use
\special{pdf:content q} for
beginning one and \special{pdf:content Q} for ending one. However, in
this case, text
contents no longer follow the relative coordinate. That was the most
critical problem.
2. \special{pdf:liternal [direct] ... }
In 2004, while I was writing a context driver for dvidpfmx, I noticed
that pdftex's \pdfliteral
puts "1 0 0 1 cur_x cur_y cm" at beginning and "1 0 0 1 -cur_x -cur_y
cm" at the end.
So I added a new special "pdf:literal" to do the same way. But it was
not successful.
Instead, \special{pdf:literal direct ...} was handy because it writes
pdf codes directly.
3. \special{pdf:code ...}
A few days ago I added a new special "pdf:code" which is an
abbreviation of "pdf:literal direct".
4. \special{pdf:bcontent} ... \special{pdf:econtent}
These are also new. It solves the critical problem of
\special{pdf:content ...} because
inside this block, text materials are given in the relative
coordinates. I do not know
this is the best solution for the disadvantage of
\special{pdf:content ...}. But there was
no other way. Anyway, this solution was helpful to support PGF graphics.
Best regards, ChoF.
P.S. I fixed the problem in the homepage. I did not notice because my
Safari in Mac OS X
did not complain it.
More information about the dvipdfmx
mailing list