[luatex] luatex Digest, Vol 30, Issue 13

[Mohamed Bana]

Would someone please unsubscribe me.  I can't seem to do it myself.

 —Mohamed


On 22 June 2011 10:23, <luatex-request at tug.org> wrote:

> Send luatex mailing list submissions to
>        luatex at tug.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://tug.org/mailman/listinfo/luatex
> or, via email, send a message with subject or body 'help' to
>        luatex-request at tug.org
>
> You can reach the person managing the list at
>        luatex-owner at tug.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of luatex digest..."
>
>
> Today's Topics:
>
>   1. Re: dump a tfm to a file (Ulrike Fischer)
>   2. Re: dump a tfm to a file (Ulrike Fischer)
>   3. Re: dump a tfm to a file (Taco Hoekwater)
>   4. Re: dump a tfm to a file (Luis Rivera)
>   5. Re: dump a tfm to a file (Khaled Hosny)
>   6. Re: dump a tfm to a file (Ulrike Fischer)
>   7. Re: dump a tfm to a file (luigi scarso)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 21 Jun 2011 18:30:19 +0200
> From: Ulrike Fischer <luatex at nililand.de>
> To: luatex at tug.org
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <15b67h71makxr$.dlg at nililand.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Am Tue, 21 Jun 2011 10:33:26 +0200 schrieb Mojca Miklavec:
>
> >> I know nothing about tex4ht except that it exists and is annoyingly hard
> >> to set up right (which is exactly why that is the only thing I know
> >> about it).
>
> And this from the user of a system which so hard to set up that it
> breaks permanently in miktex ;-)
>
> Actually I don't think that tex4ht is overly complicated, but yes
> tex4ht it is not really easy to debug or to get details right or to
> expand.
>
> One central problem is that not much of its "inner working" is
> known. Eitan Gurari was always very helpful on c.t.t. If someone
> mentioned a bug or a feature request a new beta arrived. But as far
> as I know he was the only one who worked with the source and
> actually understood what the various pieces do. And while there is
> some code documentation it is not helpful as it contains a lot of
> personal remarks, e-mail snippets and obviously simply evolved over
> time. And this makes it difficult to find a new maintainer, or
> someone who can help with problems and insights.
>
> But on the other side texh4t contains a lot of useful code. I was
> quite impressed some days ago when I could convert a document
> containing a biblatex bibliography without much problems to an open
> office document. And the html generation is really quite powerful
> and sophisticated. It would be a pity if one would do all the work
> again instead of trying first if it can be reused and adapted.
>
>
> >> But if there is a dedicated format that tex4ht understands,
> >> then it should be quite straightforward to create such a file based on
> >> the internal metrics representation, especially if it is a
> human-readable
> >> format.
> >
> > It is. See:
> >
> /usr/local/texlive/2011/texmf-dist/tex4ht/ht-fonts/unicode/lm/lm-ec.htf
>
> tex4ht doesn't use only this htf-files. At first it loads the tfm's
> of the fonts mentioned in the dvi (I don't know exactly why).
>
>
> --
> Ulrike Fischer
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 21 Jun 2011 18:37:50 +0200
> From: Ulrike Fischer <luatex at nililand.de>
> To: luatex at tug.org
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <m4n3f9412s4a$.dlg at nililand.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Am Tue, 21 Jun 2011 10:57:35 +0200 schrieb Khaled Hosny:
>
>
> > Or one can just ditch tex4ht entirely and go with more sane lua based
> > solution like the amazing x(h)ml export work that Hans is doing (it can
> > even export xii.tex ;) ).
>
> tex4ht can export xii.tex too. I tried ;-) And while I would
> certainly like to try Hans code: it probably doesn't work for latex,
> so it would need someone who 1. understand it and 2. can adapt it.
> Both not very easy without some good documentation.
>
> Btw: Do you have time to synch the unstable branch of luaotfload
> with the newest context code?
>
> --
> Ulrike Fischer
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 21 Jun 2011 19:42:51 +0200
> From: Taco Hoekwater <taco at elvenkind.com>
> To: "luatex at nililand.de" <luatex at nililand.de>, "General discussion of
>        LuaTeX." <luatex at tug.org>
> Cc: "luatex at tug.org" <luatex at tug.org>
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <06A802EF-6FA7-4778-81D7-FEBEA5213813 at elvenkind.com>
> Content-Type: text/plain;       charset=us-ascii
>
>
>
>
>
> On 21 jun. 2011, at 18:30, Ulrike Fischer <luatex at nililand.de> wrote:
>
> > Am Tue, 21 Jun 2011 10:33:26 +0200 schrieb Mojca Miklavec:
> >
> >>> I know nothing about tex4ht except that it exists and is annoyingly
> hard
> >>> to set up right (which is exactly why that is the only thing I know
> >>> about it).
> >
> > And this from the user of a system which so hard to set up that it
> > breaks permanently in miktex ;-)
> >
>
> Actually, that quote was me talking. I don't think Mojca would claim that
> anything at all is hard to set up ;)
>
> >> It is. See:
> >>
>  /usr/local/texlive/2011/texmf-dist/tex4ht/ht-fonts/unicode/lm/lm-ec.htf
> >
> > tex4ht doesn't use only this htf-files. At first it loads the tfm's
> > of the fonts mentioned in the dvi (I don't know exactly why).
>
> If it really needs TFMs, I do not think it can ever be compatible with
> luatex (or xetex, for that matter).
>
> Best wishes,
> Taco
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 21 Jun 2011 14:09:04 -0500
> From: Luis Rivera <jlrn77 at gmail.com>
> To: "General discussion of LuaTeX." <luatex at tug.org>
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <BANLkTimorM91Futmw9YRsiiwWw6u6J+WQw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 21/06/2011, Taco Hoekwater <taco at elvenkind.com> wrote:
> >
> > On 21 jun. 2011, at 18:30, Ulrike Fischer <luatex at nililand.de> wrote:
> >
> >>
> >> tex4ht doesn't use only this htf-files. At first it loads the tfm's
> >> of the fonts mentioned in the dvi (I don't know exactly why).
> >
> > If it really needs TFMs, I do not think it can ever be compatible with
> > luatex (or xetex, for that matter).
> >
>
> afaik, tex4ht doesn't load the tfms to generate the dvi: that's
> required by some tex engine (pdfTeX, afaik) which generates a dvi with
> some tailored suited macros (it makes three passes, to ensure the bbl,
> idx and other stuff are properly compiled); then, in the second stage,
> tex4ht deciphers the dvi with the htf files to generate some xml
> files; and in the third stage, t4ht assembles the final html/odt file
> with the xmls, the images, and all the other stuff generated by the
> previous steps. I collect that from reading the oolatex script, which
> actually controls the whole process.
>
> So, in my not very enlightened opinion, htf files are necessary only
> because the tfm files that generate a dvi may have different
> encodings, so the resulting dvi files are spaghetti encoded, and there
> is some need to ensure that appropriate utf8 sequences are produced
> from the messy dvi into the the generated xml files. htf files are
> mainly maps from 8 bit encoded fonts into utf8.
>
> If a TeX engine could read and write files properly UTF8 encoded, the
> need for htf files would be bypassed; tex4ht would only have to
> translate typesetting instructions (from a target successor of dvi
> format) into xml tags, since the encoding would be UTF8 right from the
> beginning.
>
> --
> Luis Rivera
> O< http://www.asciiribbon.org/ campaign
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 21 Jun 2011 23:05:36 +0200
> From: Khaled Hosny <khaledhosny at eglug.org>
> To: luatex at nililand.de, "General discussion of LuaTeX."
>        <luatex at tug.org>
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <20110621210536.GA15999 at khaled-laptop>
> Content-Type: text/plain; charset=utf-8
>
> On Tue, Jun 21, 2011 at 06:37:50PM +0200, Ulrike Fischer wrote:
> > Am Tue, 21 Jun 2011 10:57:35 +0200 schrieb Khaled Hosny:
> >
> >
> > > Or one can just ditch tex4ht entirely and go with more sane lua based
> > > solution like the amazing x(h)ml export work that Hans is doing (it can
> > > even export xii.tex ;) ).
> >
> > tex4ht can export xii.tex too. I tried ;-) And while I would
> > certainly like to try Hans code: it probably doesn't work for latex,
> > so it would need someone who 1. understand it and 2. can adapt it.
> > Both not very easy without some good documentation.
>
> Hans code is probably deeply tied with ConTeXt, I was only suggesting
> that someone would try a similar approach (I don't know much about
> tex4ht either, but from where I stand it looks like a big, complex and
> fragile hack that is only necessary because TeX can't do better.)
>
> > Btw: Do you have time to synch the unstable branch of luaotfload
> > with the newest context code?
>
> I don't think so, Hans did some big changes (to make the code even more
> separable) and it might require rewriting luaotfload's glue layer, but I
> can't afford time for that (I can only do small and interesting hacks :)
> for the time being.)
>
> Regards,
>  Khaled
>
> --
>  Khaled Hosny
>  Egyptian
>  Arab
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 22 Jun 2011 10:56:58 +0200
> From: Ulrike Fischer <luatex at nililand.de>
> To: luatex at tug.org
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <h0k1gi80icam.dlg at nililand.de>
> Content-Type: text/plain; charset="iso-8859-15"
>
> Am Tue, 21 Jun 2011 14:09:04 -0500 schrieb Luis Rivera:
>
> >>> tex4ht doesn't use only this htf-files. At first it loads the tfm's
> >>> of the fonts mentioned in the dvi (I don't know exactly why).
> >>
> >> If it really needs TFMs, I do not think it can ever be compatible with
> >> luatex (or xetex, for that matter).
> >>
> >
> > afaik, tex4ht doesn't load the tfms to generate the dvi: that's
> > required by some tex engine (pdfTeX, afaik) which generates a dvi with
> > some tailored suited macros (it makes three passes, to ensure the bbl,
> > idx and other stuff are properly compiled); then, in the second stage,
> > tex4ht deciphers the dvi with the htf files to generate some xml
> > files; and in the third stage, t4ht assembles the final html/odt file
> > with the xmls, the images, and all the other stuff generated by the
> > previous steps. I collect that from reading the oolatex script, which
> > actually controls the whole process.
> >
>
>
>
> To avoid some confusion: There is tex4ht as "system", large package
> with various files, folders, configuration etc. And there is the
> central application tex4ht.exe.
>
> tex4ht.exe is a dvi-driver. It takes a dvi and generates eg a
> html-file. To be able to do this the dvi must contain a lot
> \specials. This specials are inserted by tex4ht.sty and various
> 4ht-files during the previous (lua)latex runs.
>
>
> > So, in my not very enlightened opinion, htf files are necessary only
> > because the tfm files that generate a dvi may have different
> > encodings, so the resulting dvi files are spaghetti encoded, and there
> > is some need to ensure that appropriate utf8 sequences are produced
> > from the messy dvi into the the generated xml files. htf files are
> > mainly maps from 8 bit encoded fonts into utf8.
> >
> > If a TeX engine could read and write files properly UTF8 encoded, the
> > need for htf files would be bypassed; tex4ht would only have to
> > translate typesetting instructions (from a target successor of dvi
> > format) into xml tags, since the encoding would be UTF8 right from the
> > beginning.
>
> The htf-files don't do only reencoding or mapping. They are used to
> control the "look" of the output. E.g.
>
> 'b' ''     98
>
> will give the expected "b" if the input is char98 (= b). But in
> another htf-file you find at position 98 this:
>
> 'B' '4'    98
>
> and this will give
>
> <span class="small-caps">B</span>
>
> (The <span>  comes from the '4' which is a class number).
>
> So the htf-files gives you a low-level mapping characters to other
> representations (like html entities) and of fonts to font features
> in html like small-caps, bold etc.
>
>
> The generation of the dvi works fine with luatex. The problems
> starts at the dvi -> html step with tex4ht (if the document uses
> system fonts). The dvi contains font names like "file:lm-modern..."
> and tex4ht looks (for still unknown reasons) for its tfm and can't
> find it.
>
> For a simple document I got around the problem by using the
> low-level command \font\test=Arial and renaming an arbitrary tfm to
> arial.tfm.  Currently I seem to be able to use ASCII and ???, but
> the ? is output to  ?. This looks like a 256-barrier ;-(. But
> perhaps one can get around it by extending the htf-files.
>
>
>
> --
> Ulrike Fischer
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 22 Jun 2011 11:23:14 +0200
> From: luigi scarso <luigi.scarso at gmail.com>
> To: luatex at tug.org
> Subject: Re: [luatex] dump a tfm to a file
> Message-ID: <BANLkTimi32cT5DQGCT4LMEzizhoe3pvh9g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Jun 22, 2011 at 10:56 AM, Ulrike Fischer <luatex at nililand.de>
> wrote:
> > Am Tue, 21 Jun 2011 14:09:04 -0500 schrieb Luis Rivera:
> >
> >>>> tex4ht doesn't use only this htf-files. At first it loads the tfm's
> >>>> of the fonts mentioned in the dvi (I don't know exactly why).
> >>>
> >>> If it really needs TFMs, I do not think it can ever be compatible with
> >>> luatex (or xetex, for that matter).
> >>>
> >>
> >> afaik, tex4ht doesn't load the tfms to generate the dvi: that's
> >> required by some tex engine (pdfTeX, afaik) which generates a dvi with
> >> some tailored suited macros (it makes three passes, to ensure the bbl,
> >> idx and other stuff are properly compiled); then, in the second stage,
> >> tex4ht deciphers the dvi with the htf files to generate some xml
> >> files; and in the third stage, t4ht assembles the final html/odt file
> >> with the xmls, the images, and all the other stuff generated by the
> >> previous steps. I collect that from reading the oolatex script, which
> >> actually controls the whole process.
> >>
> >
> >
> >
> > To avoid some confusion: There is tex4ht as "system", large package
> > with various files, folders, configuration etc. And there is the
> > central application tex4ht.exe.
> >
> > tex4ht.exe is a dvi-driver. It takes a dvi and generates eg a
> > html-file. To be able to do this the dvi must contain a lot
> > \specials. This specials are inserted by tex4ht.sty and various
> > 4ht-files during the previous (lua)latex runs.
> >
> >
> >> So, in my not very enlightened opinion, htf files are necessary only
> >> because the tfm files that generate a dvi may have different
> >> encodings, so the resulting dvi files are spaghetti encoded, and there
> >> is some need to ensure that appropriate utf8 sequences are produced
> >> from the messy dvi into the the generated xml files. htf files are
> >> mainly maps from 8 bit encoded fonts into utf8.
> >>
> >> If a TeX engine could read and write files properly UTF8 encoded, the
> >> need for htf files would be bypassed; tex4ht would only have to
> >> translate typesetting instructions (from a target successor of dvi
> >> format) into xml tags, since the encoding would be UTF8 right from the
> >> beginning.
> >
> > The htf-files don't do only reencoding or mapping. They are used to
> > control the "look" of the output. E.g.
> >
> > 'b' '' ? ? 98
> >
> > will give the expected "b" if the input is char98 (= b). But in
> > another htf-file you find at position 98 this:
> >
> > 'B' '4' ? ?98
> >
> > and this will give
> >
> > <span class="small-caps">B</span>
> >
> > (The <span> ?comes from the '4' which is a class number).
> >
> > So the htf-files gives you a low-level mapping characters to other
> > representations (like html entities) and of fonts to font features
> > in html like small-caps, bold etc.
> >
> >
> > The generation of the dvi works fine with luatex. The problems
> > starts at the dvi -> html step with tex4ht (if the document uses
> > system fonts). The dvi contains font names like "file:lm-modern..."
> > and tex4ht looks (for still unknown reasons) for its tfm and can't
> > find it.
> >
> > For a simple document I got around the problem by using the
> > low-level command \font\test=Arial and renaming an arbitrary tfm to
> > arial.tfm. ?Currently I seem to be able to use ASCII and ???, but
> > the ? is output to ??. This looks like a 256-barrier ;-(. But
> > perhaps one can get around it by extending the htf-files.
> With context mkii (texlive 2009, pdftex engine: test.mkii is an utf-8 file)
>
> %%% test.mkii
> \enableregime[utf]
> \starttext
> goo
> ???@??
> \stoptext
> %%%
>
> $>texexec --dvi  test.mkii
> $>tex4ht test.dvi
>
>
> ----------------------------
> tex4ht.c (2009-01-31-07:33 kpathsea)
> /opt/TeXLive2009/tl2009/bin/i386-linux/tex4ht test.dvi
> (/opt/TeXLive2009/tl2009/texmf-dist/tex4ht/base/unix/tex4ht.env)
>
> (/opt/TeXLive2009/tl2009/texmf-dist/tex4ht/ht-fonts/iso8859/1/charset/unicode.4hf)
> (/opt/TeXLive2009/tl2009/texmf-dist/fonts/tfm/hoekwater/context/fmvr8x.tfm)
>
> (/opt/TeXLive2009/tl2009/texmf-dist/tex4ht/ht-fonts/unicode/marvosym/fmvr8x.htf)
> (/opt/TeXLive2009/tl2009/texmf-dist/fonts/tfm/public/lm/ec-lmr12.tfm)
>
> (/opt/TeXLive2009/tl2009/texmf-dist/tex4ht/ht-fonts/alias/lm/lm-ec/ec-lm.htf)
> Searching `lm-ec.htf' for `ec-lmr12.htf'
> (/opt/TeXLive2009/tl2009/texmf-dist/tex4ht/ht-fonts/unicode/lm/lm-ec.htf)
> [1 file test.html
> ]
> Execute script `test.lg'
>
>
> test.lg is
> ----------------------
> htfcss: ec-lmbo  font-style: oblique;
> htfcss: ec-lmbx  font-weight: bold;
> htfcss: ec-lmbxi  font-style:italic; font-weight: bold;
> htfcss: ec-lmbxo  font-style: oblique; font-weight: bold;
> htfcss: ec-lmcsco  font-style: oblique;
> htfcss: ec-lmri  font-style:italic;
> htfcss: ec-lmro  font-style: oblique;
> htfcss: ec-lmss  font-family: sans-serif;
> htfcss: ec-lmssbo  font-family: sans-serif; font-style: oblique;
> font-weight: bold;
> htfcss: ec-lmssbx  font-family: sans-serif; font-weight: bold;
> htfcss: ec-lmssdc  font-family: sans-serif;
> htfcss: ec-lmssdo  font-family: sans-serif; font-style: oblique;
> htfcss: ec-lmsso  font-family: sans-serif; font-style: oblique;
> htfcss: ec-lmssq  font-family: sans-serif;
> htfcss: ec-lmssqbo  font-family: sans-serif; font-style: oblique;
> font-weight: bold;
> htfcss: ec-lmssqbx  font-family: sans-serif; font-weight: bold;
> htfcss: ec-lmssqo  font-family: sans-serif; font-style: oblique;
> htfcss: ec-lmtcsc  font-family: monospace;
> htfcss: ec-lmtcso  font-style: oblique; font-family: monospace;
> htfcss: ec-lmtk  font-family: monospace;
> htfcss: ec-lmtko  font-style: oblique; font-family: monospace;
> htfcss: ec-lmtl  font-weight: light; font-family: monospace;
> htfcss: ec-lmtlc  font-weight: light; font-family: monospace;
> htfcss: ec-lmtlco  font-weight: light; font-style: oblique;
> font-family: monospace;
> htfcss: ec-lmtlo  font-weight: light; font-style: oblique;
> font-family: monospace;
> htfcss: ec-lmtt  font-family: monospace;
> htfcss: ec-lmtti  font-family: monospace; font-style:italic;
> htfcss: ec-lmtto  font-style: oblique; font-family: monospace;
> htfcss: ec-lmvtk  font-family: monospace;
> htfcss: ec-lmvtko  font-style: oblique; font-family: monospace;
> htfcss: ec-lmvtl  font-weight: light; font-family: monospace;
> htfcss: ec-lmvtlo  font-weight: light; font-style: oblique;
> font-family: monospace;
> htfcss: ec-lmvtt  font-family: monospace;
> htfcss: ec-lmvtto  font-style: oblique; font-family: monospace;
> File: test.html
> --- characters ---
> Font("ec-lmr","12","12","100")
> Font("fmvr8x","","10","120")
> ------------------
>
>
> The result is
>
> 1
> goo &#x20AC;??@cc
>
>
> (where 1 is the pagenumber on the header)
>
>
>
>
> --
> luigi
>
>
>
> ------------------------------
>
> _______________________________________________
> luatex mailing list
> luatex at tug.org
> http://tug.org/mailman/listinfo/luatex
>
>
> End of luatex Digest, Vol 30, Issue 13
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/luatex/attachments/20110622/6f31ffd9/attachment-0001.html>