Bug#1009196: [Dev-luatex] Bug#1009196: texlive-binaries: Reproducible content of .fmt files

2022-04-11 Thread Hans Hagen

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

2022-04-11 Thread Hans Hagen

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

2014-07-18 Thread Hans Hagen

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

2014-07-07 Thread Hans Hagen

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

2014-07-03 Thread Hans Hagen

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

2014-07-01 Thread Hans Hagen

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

2014-07-01 Thread Hans Hagen

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

2014-06-30 Thread Hans Hagen

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

2014-06-30 Thread Hans Hagen

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

2014-06-08 Thread Hans Hagen

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

2009-12-19 Thread Hans Hagen

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

2009-12-19 Thread Hans Hagen

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

2009-12-19 Thread Hans Hagen

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

2009-12-19 Thread Hans Hagen

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

2008-07-07 Thread Hans Hagen

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

2007-12-24 Thread Hans Hagen

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

2007-11-14 Thread Hans Hagen

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

2007-10-22 Thread Hans Hagen

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

2007-02-05 Thread Hans Hagen

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

2006-01-27 Thread Hans Hagen

� 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

2006-01-19 Thread Hans Hagen

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

2006-01-19 Thread Hans Hagen

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

2006-01-15 Thread Hans Hagen

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

2005-12-03 Thread Hans Hagen

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

2005-08-27 Thread Hans Hagen Outside

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

2005-06-29 Thread Hans Hagen

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
-