ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: Vladimir Lomov <lomov.vl@gmail.com>, ntg-context@ntg.nl
Subject: Re: Dubious "checksum mismatch" message on log file
Date: Thu, 02 Feb 2012 09:45:01 +0100	[thread overview]
Message-ID: <4F2A4D0D.1010203@wxs.nl> (raw)
In-Reply-To: <20120202012103.GL13420@smoon>

On 2-2-2012 02:21, Vladimir Lomov wrote:

> Correct me if I'm wrong, but this how I understand TFM font and currect
> state of tex engines (actually pdftex, xetex and luatex):

sort of wrong

> 1. to use any font in tex one need a TFM file (file name = fontname.TFM),
> that file actually contain informationabout font, not how exatly glyphs
> are constructed;

indeed, and when we forget about opentype etc only the tfm is needed

> 2. when [original] tex read a document file it searches for TFM and VF
> files, read them and write DVI file with information about that files;

no, the vf is only needed when the backend (which happens to be included 
in pdftex/luatex) is going to embed the glyph data from the font; only 
then it needs to know of a glyph is actually a virtual one

however, in luatex, due to different internals, vf files are / can be 
read in earlier as the virtual font model is part of the front end

so, it can be in an earlier stage that some mismatch can happen

> 3. after that user can send file to printer or publisher to print it on
> printer. As I understand the purpose of checksum was to be sure that
> publisher or printer would use exatly the same fonts as user. If user
> converts DVI file to PS/PDF one on his/she computer using dvips or
> dvipdfm* the checksum mostly useless, assuming files are not corrupted.

no, the checksum only is some safeguard that vf and tfm match

if you go through dvi then dvips or dvipdfmx read the vf files

> Nowadays pdftex, xetex and luatex are widely used and most time users
> generate PDF files on the same computer they write documents, send PDF
> files which have they own mechanism to check font consistency.
>
> But still there are [plenty] DVI files around, as well as luatex engine
> might generate DVI file. The convertion to PS/PDF is performed by
> dvips/dvipdfm* programs, that's ok. But what about luatex with DVI
> output?

i never use luatex with dvi output

> My conclusion:
> 1. if PDF output is only interesting then it is Ok, ignore that message,
> because font information is already in PDF and PDF programs should deal
> with it;
> 2. if DVI output is concerned then luatex _must_ be consistent with
> pdftex (also can write DVI files), which, imho (don't check), takes care
> about both TFM and VF checksums.

luatex probably is consistent although in most cases the way that it 
deals with fonts (read: the macro package deals with fonts) is different 
from the way it's done with pdftex/xetex

if i had the time i'd probably run a few tests and see where the 
mismatch happens but it has a real low priority for me

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


  parent reply	other threads:[~2012-02-02  8:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-01  1:09 Vladimir Lomov
2012-02-01  1:37 ` luigi scarso
2012-02-01  6:00   ` Vladimir Lomov
2012-02-01  7:45     ` luigi scarso
2012-02-01  9:21       ` Vladimir Lomov
2012-02-01  9:54         ` luigi scarso
2012-02-01 13:48           ` Vladimir Lomov
2012-02-01 14:04             ` luigi scarso
2012-02-02  1:28               ` Vladimir Lomov
2012-02-02  1:34                 ` luigi scarso
2012-02-01 14:15           ` Ulrike Fischer
2012-02-01 14:22             ` Hans Hagen
2012-02-02  1:21               ` Vladimir Lomov
2012-02-02  8:43                 ` Ulrike Fischer
2012-02-02  8:45                 ` Hans Hagen [this message]
2012-02-01 14:47             ` luigi scarso
2012-02-01 15:51               ` Khaled Hosny
2012-02-01 15:23             ` Khaled Hosny
2012-02-02  8:54               ` Ulrike Fischer
2012-02-02 12:30           ` luigi scarso
2012-02-02 14:47             ` luigi scarso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F2A4D0D.1010203@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=lomov.vl@gmail.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).