[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