[XeTeX] Lucida Bright problem with 0.997

[Stephen Moye]

On Jul 28, 2007, at 3:41 PM, Jonathan Kew wrote:

> On 28 Jul 2007, at 7:55 pm, Stephen Moye wrote:
>
>>
>> On Jul 28, 2007, at 2:42 PM, Stephen Moye wrote:
>>
>>> The code at the end of this note works with pdflatex and xelatex
>>> (0.996), but causes this error with xelatex 0.997:
>>>
>>> Package fontspec Warning:
>>>     Adjusting the maths setup (use [no-math] to avoid this).
>>> This warning occured on input line 33.
>>>
>>> [1] (./testart.aux)
>>> Output file removed.
>
> This message comes from xdvipdfmx if it encounters an error of some
> kind and is unable to continue generating the pdf. You're getting it
> with the latest xetex because it now uses xdvipdfmx by default, and
> apparently that can't handle your document. :-(
>
> Running "xelatex -no-pdf testart.tex" followed by "xdvipdfmx -vv
> testart.xdv" may give some clues, as xdvipdfmx with the -vv option
> will report its progress so you might see where it dies
>
> What format are your Lucida Bright fonts? Are you perhaps using an
> old set of "classic-style" LWFN PostScript fonts and an accompanying
> suitcase of bitmaps?

Yes. The following output from "xdvipdfmx -vv testart.xdv" would seem to
support that:

16:13 ~/Desktop% xdvipdfmx -vv testart.xdv
DVI Comment:  XeTeX output 2007.07.28:1612
testart.xdv -> testart.pdf
<AGL:texglyphlist.txt>[1<LucidaBright(LucidaBright:Lucida Bright) 
@9.93pt<NATIVE-FONTMAP:LucidaBright/H>
fontmap: LucidaBright/H -> LucidaBright/H(Identity-H)

pdf_font>> Input encoding "Identity-H" requires at least 2 bytes.
pdf_font>> The -m <00> option will be assumed for "LucidaBright/H".
 >
** ERROR ** Invalid font: -1 (0)

Output file removed.
16:13 ~/Desktop%

===

What font formats would not incur the error? OT, obviously -- any  
others?


> I haven't tried any such fonts lately but it
> could be that xdvipdfmx doesn't handle them; looking into this is on
> my "to do" list, but I haven't got to it yet.
>
> If you run xelatex with the option  -output-driver=xdv2pdf  it should
> revert to 0.996-style behavior, but this is only a workaround, not a
> proper explanation/solution.

I'll try that for the moment. Thanks.

Stephen