Re: Regression testing of tetex
Hi,
> > One thing that I am worried, from my perspective is that i18n isn't
> > too tested, because it's often not obvious how to run tex files of
> > languages other than your own.
>
> The language documentation packages of texlive should provide some
> examples. tetex also has some - do you want us to collect a list?
A pointer would be nice.
I've googled and found a file there:
http://www.tug.org/texlive/Contents/live/texlive/texmf-doc/doc/japanese/lshort-japanese/
and realized that the produced .pdf file in that directory is
gibberish with lots of '$' signs. It's not that Japanese consists of
so much dollar signs, but it's byproduct of Japanese text not being
handled properly. As a result Japanese is turned into a language full
of american bucks. Yikes.
Considering that the text seems to be dated since 2001, and PDF is
dated 2003, somebody built it but never noticed it was actually
broken.
For handling Japanese text, I'm using 'ptex' which is a variant of
tex. ptex doesn't have pdflatex etc., and it's lagging behind
somewhat, but that's the current state-of-affairs. There's also jtex.
Since they are derivatives texen, using some parts of tetex, they are
sometimes broken by new tetex uploads (which I tend to notice just
when my monthly presentation is due in few hours.)
> > /me checks, and rebuilding twice with dvipdfmx seems to obtain two
> > different results... Apparently they have BaseName, FontName, CMapName
> > directives different every time.
> >
> > @@ -751,7 +751,7 @@
> > /CIDInit /ProcSet findresource begin
> > 12 dict begin
> > begincmap
> > -/CMapName /RXGTTZ+CMR17-UTF16 def
> > +/CMapName /WEUQPZ+CMR17-UTF16 def
> > /CMapType 2 def
> > /CIDSystemInfo <<
> > /Registry (Adobe)
>
> Sorry, I overlooked one snippet from my Makefile:
>
> %.$(OUTEXT).new: %.$(OUTEXT)
> egrep -a -v '/BaseFont|/FontName|/UniqueID|/ID|/CreationDate' $< > $@
>
> And then I check the difference between $file.pdf.new and
> $file.pdf.comp. This worked for me with the pdfTeX in teTeX 2.0.2, but
> /CMapName obviously must be added, either for dvipdfmx or also for newer
> pdfTeX versions.
Another thing that is different is the 'stream' which presumably is
the embedded font data. The font data itself seems to be the same,
but the name embedded in the header portion of the binary is
different.
I guess I can work around that by not embeddeding the font.
regards,
junichi
--
dancer@{debian.org,netfort.gr.jp} Debian Project
Reply to: