headers
Stephan Hennig | 10 Oct 2010 22:05
Picon
Favicon

Fwd: Re: [metapost] problem with 'dvips mproof'

Hi,

this is an issue with dvips and embedding MetaPost graphics that contain 
text labels originally posted on the metapost list.  I'm moving the 
issue here because the conclusion (by others) is, that it's a bug in 
dvips.  I'm fully quoting my original bug report and some relevant answers.

Best regards,
Stephan Hennig

-------- Original-Nachricht --------
Betreff: Re: [metapost] problem with 'dvips mproof'

Am 10.10.2010 17:32, schrieb Taco Hoekwater:
> On 10/10/2010 12:26 PM, Stephan Hennig wrote:
>> Am 10.10.2010 02:52, schrieb Reinhard Kotucha:
>>> On 9 October 2010 Stephan Hennig wrote:
>>>
>>>> when processing a file s.mp containing the lines
>>>>
>>>> prologues := 3;
>>>> beginfig(1);
>>>>    label("test", origin);
>>>> endfig;
>>>> end
>>>>
>>>> as
>>>>
>>>>    mpost s
>>>>    tex mproof s.1
(Continue reading)

Permalink | Reply | 9 comments |
headers
Tom Rokicki | 10 Oct 2010 22:46
Picon

Re: Fwd: Re: [metapost] problem with 'dvips mproof'

So everything works fine with prologues := 0, correct?

If that is the case, why would one want to set prologues to something else?

As for the font names for dvips, *that* sounds like a fixable thing.
Right now I believe by default dvips is compiled to use the font subsetting
code from pdftex so I'll have to investigate how to ask pdftex to save the
font with a new name, at which point it should be completely
straightforward to change the dvips code that actually invokes the font.

And then we can do the same thing for the t1part code if we suspect
anyone is using that, or else we can leave any t1part usage as-is.

But I'd like to understand more about this first, if possible.

Also, if someone can refer me to a web link or PDF document that
contains Adobe's recommendation in full on naming subsetted fonts,
I'd be very grateful; I'd like to comply as closely as possible.

-tom

On Sun, Oct 10, 2010 at 1:05 PM, Stephan Hennig <mailing_list@...> wrote:
> Hi,
>
> this is an issue with dvips and embedding MetaPost graphics that contain
> text labels originally posted on the metapost list.  I'm moving the issue
> here because the conclusion (by others) is, that it's a bug in dvips.  I'm
> fully quoting my original bug report and some relevant answers.
>
> Best regards,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stephan Hennig | 11 Oct 2010 00:33
Picon
Favicon

Re: Fwd: Re: [metapost] problem with 'dvips mproof'

Am 10.10.2010 22:46, schrieb Tom Rokicki:
> So everything works fine with prologues := 0, correct?

Pretty much, yes. I'm not exactly sure, because there is the slightly 
different rendering between prologues:=0 and 1 when zooming in with PS_View.

> If that is the case, why would one want to set prologues to something
> else?

Good question.  The MetaPost manual was never good at explaining 
prologues in detail.  Additionally, the following paragraph from mpman 
as of MetaPost v0.641 (found on TeX Live 7 dating 2002) somehow disappeared.

> Giving this internal variable a positive value causes causes output
> to be formatted as "structured PostScript" generated on the
> assumption that text comes from built-in PostScript fonts. This makes
> MetaPost output much more portable, but it has an important drawback:
> It generally does not work when you use TEX fonts, since programs
> that translate TEX output into PostScript need to make special
> provisions for TEX fonts in included figures and the standard
> PostScript structuring rules do not allow for this.

(Fortunately, 'svn cat -r 1 mpman.tex' reveals the paragraph didn't 
exist more than a year before I got an svn account.)

The current description of prologues ends with

> It is worth noting that the default value prologues:=0 is sufficient
> for graphics included in TEX-based documents. Also, the prologues
> variable is irrelevant when processing MetaPost files through the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reinhard Kotucha | 11 Oct 2010 02:26
Picon

Re: Fwd: Re: [metapost] problem with 'dvips mproof'

On 10 October 2010 Tom Rokicki wrote:

 > Also, if someone can refer me to a web link or PDF document that
 > contains Adobe's recommendation in full on naming subsetted fonts,
 > I'd be very grateful; I'd like to comply as closely as possible.

http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf

section 5.5.3, page 419

Regards,
  Reinhard

--

-- 
----------------------------------------------------------------------------
Reinhard Kotucha			              Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover	                      mailto:reinhard.kotucha@...
----------------------------------------------------------------------------
Microsoft isn't the answer. Microsoft is the question, and the answer is NO.
----------------------------------------------------------------------------
Permalink | Reply | 1 comment |
headers
Martin Schröder | 11 Oct 2010 12:04
Picon

Re: Fwd: Re: [metapost] problem with 'dvips mproof'

2010/10/11 Reinhard Kotucha <reinhard.kotucha@...>:

> http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf

Please use
   http://www.adobe.com/devnet/pdf/pdf_reference.html
and
   http://www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Best
   Martin
Permalink | Reply | 0 comments |
headers
Peter Dyballa | 13 Oct 2010 14:08
Picon
Favicon

The dvitype utility can't dump XDV files

Hello!

The disdvi utility can dump the contents of XDV files from XeTeX,  
although not in that detail one might wish. When I try to use dvitype  
('dvitype File.xdv' or 'dvitype File.xdv.dvi' using either the hard  
link or the modified copy) it complains:

	This is DVItype, Version 3.6 (TeX Live 2010)
	Options selected:
	  Starting page = *
	  Maximum number of pages = 1000000
	  Output level = 4 (the works)
	  Resolution = 300.00000000 pixels per inch
	identification in byte 1 should be 2!
	numerator/denominator=25400000/473628672
	magnification=1000;       0.00006334 pixels per DVI unit
	' XeTeX output 2007.12.22:1710'
	Bad DVI file: ID byte is 5!
	Exit 1

although I changed the second byte in the XDV file from 5 (^E) to 2  
(^B):

	od -N 32 -t x4 File.xdv.dvi
	0000000          f7020183        92c01c3b        00000000         
03e81d20
	0000020          58655465        58206f75        74707574         
20323030
	
	od -N 32 -t x4 Real.dvi
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter Breitenlohner | 13 Oct 2010 16:56
Picon
Favicon

Re: The dvitype utility can't dump XDV files

On Wed, 13 Oct 2010, Peter Dyballa wrote:

> The disdvi utility can dump the contents of XDV files from XeTeX, although 
> not in that detail one might wish. When I try to use dvitype ('dvitype 
> File.xdv' or 'dvitype File.xdv.dvi' using either the hard link or the 
> modified copy) it complains:
>
> 	This is DVItype, Version 3.6 (TeX Live 2010)
> 	Options selected:
> 	  Starting page = *
> 	  Maximum number of pages = 1000000
> 	  Output level = 4 (the works)
> 	  Resolution = 300.00000000 pixels per inch
> 	identification in byte 1 should be 2!

Hi Peter,

this line could be misleading

> 	numerator/denominator=25400000/473628672
> 	magnification=1000;       0.00006334 pixels per DVI unit
> 	' XeTeX output 2007.12.22:1710'
> 	Bad DVI file: ID byte is 5!
> 	Exit 1

this msg probably comes from the postamble!

> although I changed the second byte in the XDV file from 5 (^E) to 2 (^B):

did you also change the id_byte at the end, i.e.in the postamble?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Dyballa | 14 Oct 2010 00:40
Picon
Favicon

Re: The dvitype utility can't dump XDV files


Am 13.10.2010 um 16:56 schrieb Peter Breitenlohner:

> did you also change the id_byte at the end, i.e.in the postamble?

No, I did not think of this "doppelte Buchführung". (Changing it  
produces more output and more errors like:

	byte 576 is not postpost!
	bad postamble pointer in byte 577!
	identification in byte 581 should be 2!
	Bad DVI file: signature in byte 582 should be 223!
)

>
>> Could dvitype learn to "officially" support XDV files in order to  
>> be able to debug them or compare the output from different XeTeX  
>> versions?
>
> Possibly, probably as a separate program similar to pdvitype for  
> japanese
> dvi file as produced by pTeX.  As a prerequisite one would need a very
> precise description of the XDV format.

It must be in xetex.ch. There the changed DVI type ID is documented –  
at the beginning of almost 10,000 lines. The most important changes  
are a possible vertical writing direction and that all characters used  
are in UTF-16 encoding – possibly similar to pTeX. Possibly different  
is the use of US-ASCII for recording \special's and font names.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Breitenlohner | 14 Oct 2010 15:32
Picon
Favicon

Re: The dvitype utility can't dump XDV files

On Thu, 14 Oct 2010, Peter Dyballa wrote:

> Am 13.10.2010 um 16:56 schrieb Peter Breitenlohner:
>> 
>> ...  As a prerequisite one would need a very
>> precise description of the XDV format.
>
> It must be in xetex.ch. There the changed DVI type ID is documented ? at the 
> beginning of almost 10,000 lines. ...

It is, but unfortunately not "very precise".

Apart from a somewhat sloppy notation in xetex.ch where, e.g., l.3614
 	\yskip\hang|pic_file| 251 flags[1] t[4][6] p[2] len[2] path[l]
ought to read
 	\yskip\hang|pic_file| 251 flags[1] t[4][6] p[2] len[2] path[len]
and moreover t[4][6] should probably be specified either as six 4-Byte or as
four 6-Byte quantities

the description (A) of |define_native_font| (252) in xetex.ch is not
consistent with the implementation (B) in XeTeX_ext.c.

A&B: if flags & COLORED => additional fields
A&B: if flags & VARIATIONS => additional fields
A: if flags & MATRIX => additional fields
B: if flags & EXTEND => additional field
B: if flags & SLANT => additional field
B: if flags & EMBOLDEN => additional field

It may well be that all these are hardly ever used, but...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Dyballa | 14 Oct 2010 17:50
Picon
Favicon

Re: The dvitype utility can't dump XDV files


Am 14.10.2010 um 15:32 schrieb Peter Breitenlohner:

> On Thu, 14 Oct 2010, Peter Dyballa wrote:
>
>> Am 13.10.2010 um 16:56 schrieb Peter Breitenlohner:
>>> ...  As a prerequisite one would need a very
>>> precise description of the XDV format.
>>
>> It must be in xetex.ch. There the changed DVI type ID is  
>> documented ? at the beginning of almost 10,000 lines. ...
>
> It is, but unfortunately not "very precise".

Then the author, Jonathan Kew, must be asked. He also wrote the  
patches to extend dvipdfmx to xdvipdfmx. (For Mac OS X xdv2pdf exists,  
whose further development has stopped a few years ago.)

--
Greetings

   Pete

A designer knows he has arrived at perfection not when there is no  
longer anything to add, but when there is no longer anything to take  
away.
				– Antoine de Saint-Exupéry
Permalink | Reply | 0 comments |

Gmane