Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files
On 4/11/2022 4:34 PM, Roland Clobus wrote: The texlive-binaries in Debian contain an embedded copy of Lua 5.3. The Lua 5.4 version of luai_makeseed is more complex, see [2]. I'll write a feature request for Lua later, that is out-of-scope for this scenario. fyi: it is unlikely that luatex will move to 5.4 because it might break exisiting code and/or introduce incompatibilties (so we assume 5.3 for now) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -
Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files
On 4/11/2022 6:56 AM, Norbert Preining wrote:
Hi Luigi, hi all luatex devs,
here at Debian we got a bug report about reproducability of luatex
format dumps. It contains a patch to make the hyphenation exception list
sorted. (I attach the patch)
Could you please take a look whether this is still relevant for the
latest release of luatex.
it actually defeats one of the security properties of lua (which was
explicitly introduced at some point: make sure that hashes have random
order each run so that it's harder to retrieve sensitive data from mem)
that said, it means that as soon as something gets stored in the format
otherwise (than exceptions) one can face the same issue (although one
can work around that by sorting etc)
if you want reproducibility for some testing, mess with this instead:
#if !defined(luai_makeseed)
#include
#define luai_makeseed() cast(unsigned int, time(NULL))
#endif
anyway, formats with embedded lua data (serialized or bytecode is never
guaranteed the same unless one does soem effort)
fwiw: the easiest solution is to not store patterns and exceptions in
the format and just load them runtime which is just as fast (in
retrospect not a good idea to store it but it was needed for some plain
compatibility testing)
Hans
(who in the past has been bitten by this 'random feature' when we made
the switch to 5.3, or maybe it was even 5.2; it used to be 'random per
binary' and became 'random per run' but we decided to stick with
official lua)
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/18/2014 1:35 PM, Fabian Greffrath wrote:
Am Donnerstag, den 17.07.2014, 20:57 -0400 schrieb James Cloos:
A patch has at least been proposed for poppler to treat glyph names like
/f_i as equivilent to names like /fi, at least for the f-ligs found in
the standard pdf font encodings for the base14 fonts.
I am still convinced (and as far as I understand it seems that at least
Karl Berry agrees in that regard) that the most portable solution would
be to include duplicates of the two "fl/f_l" and "fi/f_i" glyphs that
are part of the MacRoman character set in the fonts - in addition to and
independent of the fixes in poppler.
of course that will then fail again when someone drops in another times
replacement that doesn't have the /ff
if dropping in otf files for type 1 ones is considered a valid solution,
then poppler should do more checking anyway for the few f related
ligatures (which makes me wonder why the otf file is used as drop-in)
(apart from potential issues in one-to-one slot-to-name mapping
resolvers in other programs that now can get confused when ff overloads
f_f)
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
-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/7/2014 10:08 AM, Fabian Greffrath wrote: Isn't Times one of the fonts that are by definition of the PDF standard explicitely not required to get embedded? Those 7+bit times of a default minimal set of 15 fonts (these were embedded in printers which at some point made sense due to bandwidth et etc) are behind us. Of course most printers will still have these fonts because they are part of old standards. Not embedding a font has no benefits and for archival pdf (a/x) fonts have to be embedded. (Nowadays a mediocre picture taken by some gadget takes more space than a font in a document.) In fact, if I get a pdf file with no fonts embedded and it doesn't show up ok, I'd not even bother figuring out why and simple discard the pdf. Now, adding ff as well as f_f to a font mapping to the same glyph might work ok for applications that look for ff but it might as well confuse applications that like to see f_f (think of a one-to-one mapping: which one wins ff <-> some slot or f_f <-> slot ?). So, i guess some testing is needed as fixing one and breaking another set of applications doesn't help. So, all applications that want to support the old stuff and new stuff need to support (ff, f_f) <=> slot mapping. 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 - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/2/2014 4:32 PM, Boguslaw Jackowski wrote: Hans: I think even the type1 texgyre isn't by definition metric compatible. Metric compatibility was one of the major targets of the TeX Gyre project. Sure, definitely for the type1s, but also that for opentype we would not be strict (one never knows what follow up we will have). Visually there are of course differences (accent placement etc) so one can expect visual differences when doing trickery that depends on exact visual properties (like putting multiple accents on top of things) in which case probably even the type1 drop in could be a problem. (I'm talking tex now where open type fonts don't have the type1/tfm relates limitations in w/h/d). In practice a document that doesn't embed and expects e.g. times is not typeset that clever so problems are unlikely to show up. (Users who don't embed shouldn't complain about quality of rendering anyway.) Hans ps. A way bigger nightmare can be lucida as there are many incompatible variants of that one and then there are also cross platform viewing issues. But I assume these are normally embedded, but even then bad things can happen, e.g. with included images in documents that have no embedded fonts too. But afaik we left that time behind us. - 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 - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 6:12 PM, Ralf Stubner wrote:
On Tue, Jul 1, 2014 at 2:13 PM, Hans Hagen wrote:
The pdf file has then this mapping with fi being named f_i and not fi (why
should it) and also carries a tounicode which maps the <1> to unicode e and
<2> to unicodes f followed by i. The reference to ff never ends up in the
subsetted file.
I suspect that the pdf was created using glyph names and metrics for
Times, where fi and not f_i is used, but the font was not embedded. On
viewing the pdf, the font used instead of Times was the OpenType
version of TeX Gyre Termes, which has no glyph named fi. In this case
it should help to supply copies of the ligature glyphs using old style
names (fi and fl only).
Isn't it better then to install the standard ps set on the operating
system and make sure these are not remapped? The texgyre opentype fonts
are not supposed to be drop ins for those standard (15 or so) ps fonts.
I think even the type1 texgyre isn't by definition metric compatible. It
might be interesting to see how other viewers/operating systems behave
(e.g. do mupdf based viewers have the same side effect?)
I think that for that embedding the times and so is kind of mandate
nowadays. Those big cjk fonts are often extern but these have well
defined vectors. Personally I'd not spend a second on a user complaint
that concerns a not-embedded font.
(Btw, a bigger issue is actually that only a few viewers do 'copy' well
i.e. deal with tounicode vectors.)
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
-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 1:40 PM, Fabian Greffrath wrote: Am Dienstag, den 01.07.2014, 08:08 +0900 schrieb Norbert Preining: or adding another fake glyph fi/f_i, Yes, please. This sounds like the best compromise: It retains backward and forward compatibility, should be trivial to implement and should be safe for future changes that poppler (or any other rendering framework) introduce. I have no clue what this will solve. Say that the original input stream has this: effe = e f i e and the feature processor turns that into which in the pdf stream can become <1><2><1> with 1 pointing glyph representing e and 2 representing fi. The pdf file has then this mapping with fi being named f_i and not fi (why should it) and also carries a tounicode which maps the <1> to unicode e and <2> to unicodes f followed by i. The reference to ff never ends up in the subsetted file. Just fix poppler, because it it has this problem with f_i it definitely has more such problems. 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 - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 7/1/2014 1:05 AM, Norbert Preining wrote: On Mon, 30 Jun 2014, Hans Hagen wrote: btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. Interestingly I cannot trigger the bug with xelatex and Palatino Sans, for example. If I understand right, the bug has to do with viewing (rendering) a glyph in a pdf file. In pdf the page stream has numbers pointing to a (normally) subset index which in turn maps onto the font slots (can be any order). Normally no glyph name is involved in that. Those names might kick in when copying is involved and no tounicode mapping is present in the pdf. As you mention in a previous mail, it's a bug in poppler (or maybe some library it uses) that somehow used glyph names. I agree that there is no need to change the font (and I cannot predict what other issues might show up by duplicating glyph names; for instance turning f + i into an fi glyph .. it would still map onto the one associated with f_i). Using the unicode ligature sis a bad idea anyway as all these ligs in unicode make not much sense and is just there to suit bad old times. 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 - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742767: TeX Gyre OpenType and wrongly(?) named glyphs
On 6/30/2014 1:15 PM, Boguslaw Jackowski wrote: Norbert: here at Debian recently a problem surfaced with respect to the OpenType TeX Gyre fonts. The problem is that the ligatures are named f_i etc while display engines like poppler, as well as the orginal PostScript fonts, use fi etc. In Debian and Ubuntu, currently the TeX Gyre fonts provide the *standard* postscript fonts, due to be considered generally better. But that means, that at the current moment of one uses the TeX Gyre fonts as a replacement for the PS fonts, the ligatures will not be rendered at all. [...] Related bug reports are: * Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742767 * FreeDesktop: https://bugs.freedesktop.org/show_bug.cgi?id=73291 Dear Colleagues, we are more than happy that the TeX Gyre collection of fonts has been have been chosen as a default font set in Debian distribution. And we are sorry that we haven't predicted the problem of the discrepancy between the "new" and "old" ligatures name. Our idea was to provide "partially new" fonts. More precisely, we have assumed that the fonts in the Type 1 format should be "as compatible as possible" with the Adobe original fonts. In particular, we tried to preserve (with some exceptions, due to obvious Adobe's bugs) the original font metric and, moreover, we used the "old-style" names for ligatures. The fonts in the OTF format, however, we considered "new" ones (note, e.g., that they have Unicode tables and that they are equipped with the OTF typografic features, both absent from the original Adobe fonts) and, therefore, following Adobe's recommendations for the glyph naming in new fonts (see the mentioned by Karl documentation http://sourceforge.net/adobe/aglfn/wiki/AGL%20Specification and also Adam Twardoch's John Hudson's comments -- http://typophile.com/node/18452 and http://typophile.com/node/0 , respectively), we assigned the new-style ligature names. Indeed, so it's f_i etc and using fi for that and foo_bar_whatever for other ligatures makes no sense ... tounicode logic depends on conventions like the _ as ligature separator. In the TeX Gyre Math fonts we also have used the new-style ligature names. Two questions: 1. What about using Type 1 fonts for "compatibility purposes"? It seems to us taht it could be the simplest "patch", provided the font rendering engines are able to handle conveniently "obsolete" Type 1 fonts. 2. Does it make really sense to make a step backward and revert to the old-style names in the OTF TeX Gyre fonts (including TeX Gyre Math)? It is feasible, but we are rather reluctant to introduce such a change, as it is likely to cause fuss among TeX Gyre users. It makes no sense ... if poppler does something with glyphnames (and i'm not sure why it would) it should deal with it properly and recognize "u", "uni", "index", numbers, "_", "." ... as classifiers and separators. Dealing with inconsistencies in unicode and fonts is already a pain and adding more confusion makes no sense. btw, If I grep my afm files for f_f and f_l I get lots of hits on linotype fonts like palatino-nova, aldus-nova, palatinosans* so there are type one fonts out there that use _ too. 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 - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750785: Slowness with context and xetex
On 6/8/2014 9:26 AM, Norbert Preining wrote:
Hi Hans, hi Taco,
(please keep the Debian bug report in Cc)
We got a report here at Debian that context when run over xetex
is extremely slow, which I can confirm.
It is interesting that when I drop the original TeX Live (not Debian)
xetex into our /usr/bin, then it is getting fast again.
On the other hand, I don't see any slow down when running
xelatex on a similar document. The test document is a simple
\starttext
lots of lorem ipsum in paragraphs
\stoptext
If I change this to a simple latex document {article} it is also
very fast.
So that points at something that context is telling xetex to do/load
that exhibits a bug, but I have *NO* idea where the bug might
come from.
Can you see if (in the background) the xetex font database gets
regenerated? I remember that long ago on windows we had a problem with
xetex, where it could not determine that it had already generated the
database. This can happen when a font is asked for 'by name' which isn't
on the system so that some kind of 'not found, let's regenerate the
database' action happens (which is out of context control).
The difference between TL original and Debian is that we use
shared libraries. For pure text processing the fault should be
in harfbuzz, right? We are having 0.9.28.
Do you have any other ideas how to track such a bug? Do you have
any guess what could it be that context tells xetex?
Thanks a lot
Norbert
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
--
-
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
-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Martin Schröder wrote: 2009/12/19 Hans Hagen : yes but how does it check if the libs are functionally the same? APIs are versioned and checked by the loader. http://en.wikipedia.org/wiki/Dynamic_library#Dynamic_linking It works. Mostly. sure, but i wonder what this means for the texlive updater ... will it also ship upgraded (or ancient) library versions then? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Hi Norbert No, only that as long as the libraries in texlua are the same as upstream I can reuse the the packages in Debian. what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Martin Schröder wrote: 2009/12/19 Hans Hagen : what does that mean in practice for your tex live installer? that it has to fetch (and compile) extra libs? Debian: Dynamic libs. TeXlive: Mostly static binaries. yes but how does it check if the libs are functionally the same? Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#441595: [Dev-luatex] (fwd) Bug#441595: not all libraries are customized, there is room for improvement
Norbert Preining wrote:
Dear Taco,
one of the lua Gurus here at Debian checked the embedded libs and found
that most of the included libs are very similar to upstream, and he
offered to push the few changes in your code to upstream.
What do you say? (See attached email, including the diffs between current
upstream of the lua libs and code in texlua).
TeX has alwaye been independent of external libraries, although for
pdftex it's possible to keep some libs external. Although the 'teams'
assume statics, its' up to the distributers to decide on external libs;
kpse has been an example for a long time already but that one lives
alongside tex.
For luatex it's somewhat different. Take for instance a moving target
like lpeg. Macro packages depend on the functionality as defined when
the luatex version came around. If some (maybe more recent) library is
used it might break things. And it might even be that at some point when
we have luatex version 1.0, we freeze on libraries (apart from bug fixes
of course). The same might happen with lua itself. If lua 6 comes around
we might add an extra lua engine but keep 5 around as well.
Loading libraries in luatex can become a nightmare esp when we thing of
mixes with luarocks and other distributions. As lua is meant for
embedding, the libs we use are also kind of internal.
Of course, pushing changes/patches upstream is great.
This is a tricky issue. In principle luatex, once stable, should run
decades as-is. An independent entity. On th eother hand, progress is
also a nice thing.
I can imagine a scenario where we have a static luatex as usual, but
when distributers want to go dynamic they should use the (in terms of
api) same libs as static. None of us is looking forward to getting bug
reports like "luatex+macropackage reports an lpeg error" which only
happens with non statics bins.
Also, i wonder, if luatex demands some specific lib version, how does
this translate to installation? Currently i can just drop a static
luatex bin in my tex bin path but what if a bunch of extra libs (maybe
already present but potentially conflicting) are used? Ok, we can
control things with the cpath variable, but that also adds another
variable to the game.
Anyhow, this needs quite a bit of thinking.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#448700: [Dev-luatex] luatex loading old hyphenation patterns
Norbert Preining wrote: Hi Taco, hi all, I am trying to activate the latex based fromats of luatex in the Debian packages, but stumbled over problematic hyphenation patterns. Currently, luatex dies on tex/generic/ukrhyph/ukrhypmp.tex as shipped with TL2007, it contains Ukrainian hyphenation patterns in LCY (cp866nav) encoding. I guess that one cannot do anything here but wait for TL2008 with the new utf8 patterns to hit Debian. Right? indeed, only utf8 Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457622: (fwd) Bug#457622: context: Importing mps files from latex is broken
Norbert Preining wrote:
Dear Hans, dear Taco, dear all,
we got a bug report on Debian after shipping context 2007.12.18 wrt
supp-pdf.tex, including .mp does not work anymore ...
quick fix [EMAIL PROTECTED]
i'll look into it
- Forwarded message from Dylan Thurston <[EMAIL PROTECTED]> -
[Loading MPS to PDF converter (version 2006.09.02).]
) [MP to PDF] (./test-0.mps
! Undefined control sequence.
\doflushMPtext #1->\edef \!!stringa [EMAIL PROTECTED]
\dodoflushMPtext \!!stringa \re...
l.16 (Test) cmr10 9.96265 fshow
Minimal test files are:
- test.tex --
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\includegraphics{test-0}
\end{document}
- test.mp ---
beginfig(0);
draw (0,0)--(1cm,1cm);
label.lft("Test", (0,0));
endfig;
end
--
The error didn't occur with the supp-pdf.tex from context 2007.09.28.
I checked the two supp-pdf.tex codes and there are quite a lot of
differences. Is this a know problem and how should it be fixed?
Thanks a lot, all the best, and merry christmas
Norbert
---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
GOOSECRUIVES (pl. n. archaic)
A pair of wooden trousers worn by poultry-keepers in the Middle Ages.
--- Douglas Adams, The Meaning of Liff
--
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447559: [dev-context] Bug#447559: chemtex is broken again
Soeren Sonnenburg wrote: On Mon, 2007-10-22 at 16:18 +0200, Hans Hagen wrote: Norbert Preining wrote: forwarded 447559 [EMAIL PROTECTED] thanks Hi Hans, hi all! We got the following bug report for the Debian package, but I guess that should be fixed upstream: for latex, ppchtex is loaded via ppchtex.noc which says ... \let\normalunexpanded\unexpanded \input supp-mis.tex \let\writestatus\undefined \input syst-gen.tex \input syst-fnt.tex \let\unexpanded\normalunexpanded (\unexpanded is an etex primitive but context had an \unexpanded before etex came around; same for \protected as primitive; so here we push and pop the meanings) so, i wonder if this user loads ppchtex in the right way (maybe i should make a derived version for latex usage - given that there are users - in which case i can also cleanup and optimize the context variant, but it has low priotity) OK I got like two reports from different users who exactly had the same problem. One fixed it by simply inputting everythin in the .tex file: \input supp-mis.tex \input syst-gen.tex \input syst-fnt.tex \input m-pictex.tex \input m-ch-en.tex the other removed the lines \let\normalunexpanded\unexpanded \let\unexpanded\normalunexpanded from ppchtex.nox . Then it worked for both. So whatever you do please fix it as it is a bug that does not only annoy me or alternatively tell us please how to correctly use m-ch-en ... well, does the \let\normalunexpanded\unexpanded \input supp-mis.tex \let\writestatus\undefined \input syst-gen.tex \input syst-fnt.tex \let\unexpanded\normalunexpanded method work? i cannot test it since i only run context Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447559: [dev-context] Bug#447559: chemtex is broken again
Norbert Preining wrote: forwarded 447559 [EMAIL PROTECTED] thanks Hi Hans, hi all! We got the following bug report for the Debian package, but I guess that should be fixed upstream: for latex, ppchtex is loaded via ppchtex.noc which says ... \let\normalunexpanded\unexpanded \input supp-mis.tex \let\writestatus\undefined \input syst-gen.tex \input syst-fnt.tex \let\unexpanded\normalunexpanded (\unexpanded is an etex primitive but context had an \unexpanded before etex came around; same for \protected as primitive; so here we push and pop the meanings) so, i wonder if this user loads ppchtex in the right way (maybe i should make a derived version for latex usage - given that there are users - in which case i can also cleanup and optimize the context variant, but it has low priotity) Hans - Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409749: [dev-context] (fwd) Bug#409749: ppchtex broken
Norbert Preining wrote:
forwarded 409749 dev-context@ntg.nl
thanks
i've added that line to ppchtex.noc (no context)
Hi Hans and all ConTeXt devs,
Please see attached bug report I got on the Debian BTS, which includes
also a fix.
- Forwarded message from Soeren Sonnenburg <[EMAIL PROTECTED]> -
From: Soeren Sonnenburg <[EMAIL PROTECTED]>
Subject: Bug#409749: ppchtex broken
Date: Mon, 05 Feb 2007 09:07:33 +0100
ppchex will always fail with
===snip===
! Undefined control sequence.
\dosetsubscript #1#2#3->\dimen 0=#3\fontexheight
#2\setxvalue {@@\string #1\...
l.158 \stopchemical
===snip===
as fontexheight is undefined in /usr/share/texmf/tex/context/base/ppchtex..tex
To fix this one needs to add the following line to ppchtex.tex
(to for example line 15)
\input syst-fnt.tex
- End forwarded message -
Best wishes
Norbert
---
Dr. Norbert Preining <[EMAIL PROTECTED]>Universit� di Siena
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
---
TUMBY (n.)
The involuntary abdominal gurgling which fills the silence following
someone else's intimate personal revelation.
--- Douglas Adams, The Meaning of Liff
___
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
--
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345604: [tex-live] Re: ConTeXt documentation in "commercial" products
� wrote:
Hans Hagen <[EMAIL PROTECTED]> wrote:
I will add the following sentence to the readme:
If you distribute \CONTEXT\ and related software on electronic media
as part of \TEX\ distributions, you may also distribute the manuals
in electronic form, preferable as provided by the maintainers of
\CONTEXT.
Does this, or the new Creative Commons license, also apply to older
versions, in particular to the version included in teTeX 3.0? In this
case we (Debian) could distribute the ConTeXt documentation in our
non-free section (still non-free because we don't have the sources
currently). And I wouldn't like to use the new version's documentation
(with its CC license) and bundle it with the ConTeXt version in teTeX
3.0, since that would cause confusion. That's why I specifically ask
whether this applies to the old version, too.
With older i assume that you mean the pdf's (we started putting manual sources under svn recently)? Sure go ahead and distribute them. I don't think there was even any restriction in distributing the pdf's at least not from my side (they have been in the tex collections in separate trees anyway). The whole licencing issue with respect to manual sources is mostly there because it concerns sources.
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345604: [tex-live] Re: ConTeXt documentation in "commercial" products
Karl Berry wrote: The main point of free documentation is to allow, in principle, someone who makes changes to the free software it describes to also update the documentation. Distributing pdf's doesn't allow that. Making a good-faith effort to distribute sources (even if not necessarily complete / guaranteed to run) does. i'd say: write a new or additional manual -) btw, the fact that tex distributions seems to differ slightly (just read messages on the context list about installing tex on linux) does not mean that those who change things also document things; in the end the questions come to the source of the program ... also, if users take pieces of manuals, rewrite it, make better manuals ... fine for me, as long as no-one bothers me ... my main point is that i don't want to be responsible for that and that i don't want to let users be confused about what version is 'the real one' Any interest in reconsidering? well, for a while now context users can download sources of manuals (more will follow) from our svn repository; if they change and patch fine, as long as they don't let it end up in the commercial publication domain (and thereby entering a real copyright mess); guess why i never published one of the manuals as book: i want copies to be freely available. I leave it to others to do that and as the licence says: potential authors are free to use the examples for that purpose (it's actually one of the reasons for making them available). if i generate an html page from an xml file, it has no source either). If you generate an html page from an xml file, the xml file is the source. i bet that there are pdf's (and maybe html's) in texlive with no sources -) (anyhow, as an escape one can always use pdftotext and then claim that he/she has clever macros that can turn the resulting text file into a nicely typeset pdf file) understand those tens of pages of legal stuff -) Well, the GPL is five pages typeset, but your point remains the same :). -) Hans ----- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345604: ConTeXt documentation in "commercial" products
Hi,
please take my apologies for bringing this up, but it seems I need to.
According to mreadme.pdf, the documentation is under a different license
than the code, with a "currently" attached to that statement.
Unfortunately, the license chosen for the documentation does not allow
inclusion in TeXLive (and Debian, hence the other Cc).
I will add the following sentence to the readme:
If you distribute \CONTEXT\ and related software on electronic media
as part of \TEX\ distributions, you may also distribute the manuals
in electronic form, preferable as provided by the maintainers of
\CONTEXT.
Btw, context documentation is part of the tex collection but not of tex
live; the reason is that tex live only ships documentation for which a
source is avaliable (and since there is never the guarantee that a
source is complete, will run, has all graphic and font resources with
it, it means that this criterium is hard to meet, i.e. what is a source:
if i generate an html page from an xml file, it has no source either).
Technically this means that a pdf file like mreadme.pdf will not be
distributed. Afaik substantial context documentation and samples (over
100 meg in pdf form) are no part of linux distributions either. But i
have absoutely no problems if the manuals are distributed (as long as it
does not cost me time).
Currently, context manuals are put (stepwise) under svn, and for
practical purposes it's done on one of our internal machines with a copy
on taco's website. However, there is no guarantee that each document
runs as intended (i.e. there are fall backs when i use for instance non
public fonts, or non public graphics, and i don't provide support for
that).
At some time I may put a zip archive with the manuals alongside the
other context zips, but i wonder is there is any interest in those tens
of megabytes.
BTW, concerning GPL and manuals ... manuals are no programs and i like
the simple and understandable CC ones; this is also the reason why i use
the CC GPL variant, because then users (and i) don't have to read and
understand those tens of pages of legal stuff -)
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347992: tetex-base: mptopdf fails when src file is not in current dir
Sanjoy Mahajan wrote:
Package: tetex-base
Version: 3.0-11
Severity: normal
File: /usr/share/texmf-tetex/scripts/context/perl/mptopdf.pl
If you run mptopdf on a metapost eps file in a subdirectory, then
mptopdf reports that it converted it. However, it actualy leaves the
output in ./mpbasename.pdf. For example:
$ mptopdf xyz/fig.11
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
...
Output written on fig.pdf (1 page, 13923 bytes).
MPtoPDF 1.3 : xyz/fig.11 is converted to xyz/fig-11.pdf
$ ls -l xyz/fig-11.pdf
ls: xyz/fig-11.pdf: No such file or directory
$ ls -l fig.pdf # here it is
-rw-r--r-- 1 sanjoy sanjoy 13923 2006-01-13 16:27 fig.pdf
Here is a patch:
--- mptopdf.pl.bak 2004-08-31 06:06:09.0 -0400
+++ mptopdf.pl 2006-01-13 16:37:15.0 -0500
@@ -22,6 +22,7 @@
use Config ;
use Getopt::Long ;
use strict ;
+use File::Basename;
$Getopt::Long::passthrough = 1 ; # no error message
$Getopt::Long::autoabbrev = 1 ; # partial switch accepted
@@ -106,8 +107,9 @@
{ system ("$command \\relax $file") }
else
{ system ("$command relax $file") }
-rename ("$_.pdf", "$_-$1.pdf") ;
-if (-e "$_.pdf") { CopyFile ("$_.pdf", "$_-$1.pdf") }
+my $pdfsrc = basename($_).".pdf";
+rename ($pdfsrc, "$_-$1.pdf") ;
+if (-e $pdfsrc) { CopyFile ($pdfsrc, "$_-$1.pdf") }
if ($done) { $report .= " +" }
$report .= " $_-$1.pdf" ;
++$done } }
ok, i patched it as you submitted (no time to test now) ; I assume that
File::Basename is always present.
Thanks
Hans
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340555: [tex-live] Re: XyMTeX in TeX live
Reinhard Kotucha wrote: "Kevin" == Kevin B McCarty <[EMAIL PROTECTED]> writes: > I'm very sorry to hear that my inquiry resulted in the removal of > XyMTeX from TeXLive. :-( It is a really useful tool. > Let's hope that when Dr. Shinsaku considers XyMTeX more polished, > he'll reconsider the license. Don't be so pessimistic. Obviously he is not satisfied with the current version and I have the impression that he is still working on it and will change the license when he thinks the software is good enough. Isn't it nice to hear that his major concern is the quality of his software? And there is plenty of time until TeXLive-2006 will be released. It is good that you asked Karl to clear the copyright. I don't think that Dr. Shinsaku will be more motivated when he sees that his copyright is ignored. i agree with this; since there are users of his macros out there, dropping may also lead to surprises, frustration, unneccessary support requests etc how about a package (zip or rpm) with 'goodies'; since user are willing to install other non-free stuff (acrobat reader and such) they probably also hav eno problems with les-free goodies (previous tex collections shipped with texmf-extra that has such things) Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316154: [tex-live] Re: Bug#316154: texmf.cfg: Close possible security problem
Hilmar Preusse wrote:
Well, the submitter spoke about some mal code sent to somebody, who
calls it and the LaTeX file does something really bad. I don't know
how realistic that scenario is. Well, normally I don't read very long
documnents before processing them
since one can open a file and write to it, one can overwrite a system file and
mess up a machine; there is not much that one can do about it, (apart from
setting permissions of files/paths) since tex jobs needs auxiliary files; just
don't process files you don't trust
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#316154: [tex-live] Re: Bug#316154: texmf.cfg: Close possible security problem
Frank Küster wrote:
Dear Thomas, dear TeXLive people,
in Debian bug report we have been asked to change the setting of
openin_any in texmf.cnf:
Joachim Breitner <[EMAIL PROTECTED]> wrote:
the shipped /etc/texmf/texmf.cfg has the following lines:
openout_any = p
openin_any = a
While the first line is so far ok, the second line means, that any LaTeX
code run on this machine has read-access like the user it runs as, that
includes /etc/passwd, ~/.ssh/id_rsa, ~/other_sensitive_file.
This by itself is no problem, but it is actually quite easy to make a
user compile mal LaTeX code and make him send you the file before he has
a look at it or, using some TeX-magick, make the read text not visible
(white on white, or very small...).
sure, but if we start assuming that kind of tex usage we're lost anyway; just as
i don't open those 'watch this nice jpg picture' i will not run a tex file from
someone i don't know (unless posted on a mailing list, but then i look into teh
file anyway); the tex file suffix is more likely bound to editing than to
processing
This is also a problem for i.e. webservices, that include LaTeX
capabilities.
Is there a specific reason why this is set to `a' by default, except
that in the old times people were friendly and peaceful ;-)?
setting it to anything else can be a pain for users; apart from many messages,
files are not seen; (keep in mind that the main audience for tex live is users
who just want to use tex, not to hack config files)
those who run tex in web apps can take care of themselves and tweak the config
file; they may want to isolate tex in more ways than only opening files; (the
average unix box is set up so that users can read lots of files and i see no
reason to make tex more restrictive);
Hans
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
| www.pragma-pod.nl
-
