[tex-k] [tex-live] xdvi problems with empty glyph

[Werner LEMBERG]

> >   xdvi-xaw.bin: Warning: Character 0 is mapped to .notdef
> >                 in font gbsnu30 (page 1), replacing by whitespace.
> 
> > Glyph 0 in virtual font gbsnlp01 maps to glyph 0 in real font gbsnu30.
> > This is indeed an empty glyph which is identical to `.notdef';
> 
> I couldn't reproduce this problem (I dont' have TeXLive available and
> tried to install the CJK package manually but failed)

Ok, attached is a small tar bundle `xdvi-problem' (I've stripped the
font gbsnu30 to the bare minimum of holding just two glyphs, `.notdef'
and `uni3000').  Just do

  TEXMF=path/to/xdvi-problem/texmf xdvi xdvi-problem.dvi

and you should get the incorrect warning message.

> - I didn't quite understand this part of your report:
> 
> > however, it is called `uni3000' (using the built-in encoding vector).
> > Somehow the mapping is screwed up.

Well, xdvi is talking about the .notdef glyph, but this glyph isn't
referenced at all -- glyph uni3000 exists in the font!

> Or is this a whitespace character that is erroneously reported as
> .notdef?

Yep.

> > A minor nit: The grammatical construction in the warning message
> > seems odd to me.  I suggest
> 
> >   Warning: Character 0 is mapped to .notdef in font gbsnu30 (page 1).
> >            Replaced with whitespace.
> 
> > or something like this.
> 
> OK, I thought "replaced by" and "replaced with" are more or less
> equivalent, but perhaps this reads better.

My nit is about `replaced' vs. `replacing', especially within a single
sentence.  Sorry for being imprecise.

> > Perhaps it's even possible to refer to the original virtual font
> > too, making it easier to identify the problematic spot in the
> > document.
> 
> I'm afraid that's not easily possible since the virtual font stuff
> works in a recursive way so that the name of the original virtual
> font isn't known at the point where the error occurs.

I'm aware of that.  I've hoped that xdvi is already tracking the
recursive chain internally (for debugging purposes, for example).
It's really not an important thing.


    Werner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xdvi-problem.tar.bz2
Type: application/octet-stream
Size: 6095 bytes
Desc: not available
Url : http://tug.org/pipermail/tex-k/attachments/20061010/cbf89d07/attachment.obj