Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Mon, Jan 13, 2014 at 10:05:50PM +0100, Mojca Miklavec wrote: On Mon, Jan 13, 2014 at 4:42 PM, Khaled Hosny wrote: I was going to write a lengthy rant on how choosing FontForge as a base for LuaTeX font loader was its biggest mistakes and how font and text layout support in LuaTeX is years behind the rest of the world because of this, but then decided not to write it :) I’m unlikely to able to convince Hans with anything in this area. But then again you could regard this as a new opportunity. Given your skill set by now I can imagine you taking over a project of adding HarfBuzz (or whatever library exactly you had in mind) support to LuaTeX. I’d love to, but 1) I don’t have enough time for it right now 2) If ConTeXt is not going to use it, then it is just as useless to me. Regards, Khaled ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
I was going to write a lengthy rant on how choosing FontForge as a base for LuaTeX font loader was its biggest mistakes and how font and text layout support in LuaTeX is years behind the rest of the world because of this, but then decided not to write it :) I’m unlikely to able to convince Hans with anything in this area. Regards, Khaled On Mon, Jan 13, 2014 at 12:32:17AM +0100, Mojca Miklavec wrote: Dear Khaled, since you were not included in the recent discussion I only wanted to briefly explain my part of the story of recent changes that took place in ConTeXt and in LuaTeX. They might be relevant for luaotfload as well, but if details are needed, Taco and Hans can probably explain better than I can. I first figured out that font database generation (which actually stores just the font name, filename and a few basic font properties, no actual info about glyphs or kerns or any other kind of huge data) took forever. I admit that I'm guilty of not having used the latest ConTeXt for a very long time already and in TL 2013 it behaved acceptable, so I only noticed it about a week or two ago (but many Mac users kept asking about ways to disable system fonts on the ConTeXt mailing list recently). I'm not sure how long that forever processing of LastResort.ttf was because I gave up after about half an hour, but it could have been 40-60 minutes or so (I think the font generation job actually finished once in the background). It turned out that something weird was going on with the font LastResort.ttf (which is also blacklisted in luaotfload, I think, based on some comments on stackexchange claiming that processing that font takes a very long time). Then both Hans and Taco fixed a few bits both in the LuaTeX engine and in ConTeXt. This reduced the time to deal with this font to about 4 seconds I think. Next I found out that extracting the name from Arial Unicode alone took about 30 seconds. Luigi and Hans objected that my computer was ultra-slow and that doing the same on their machines with SSD took 3 seconds. Hans sent me a minimal lua script to mimick the basic operations done in font generation database and it turned out that the slow part of the code was opening and closing the font when trying to extract a few parameters. And just opening the Arial font without doing anything else took that 30 seconds, while doing the same with TeX Live 2013 took just 0.15 seconds or so. Then Luigi figured out which commit was responsible for that enormous time waste and this is exactly the reverted commit. (I don't know what the proper way to deal with this is, but ending up with 30 seconds time to solely open the font seems like an overkill to me. I didn't try to understand the code, but I strongly suspect that an O(n^2) algorithm was used where an O(n) could be written if the reverted code still seems valuable/usable. I mean: glyphNameExists could easily be implemented with O(1) or O(log n), there's no need for O(n).) I was still dissatisfied with 2-3 minutes font database generation time, given that ConTeXt spent about 3-4 seconds per certain Korean fonts (Mac ships with 24 of those) and some others, so LuaTeX was further modified to provide a few extra bits of meta font information, so that ConTeXt no longer had to open any font to get sufficient information. All in all this lead to reduction of time spent on font generation database from (probably) 40-60 minutes to merely 3 seconds on my so-called old and slow notebook from 2009. I'm not sure who takes care of luaotfload, but I believe this is something worth fixing there as well. Mojca On Sun, Jan 12, 2014 at 11:51 PM, Khaled Hosny wrote: On Sat, Jan 11, 2014 at 04:30:19PM +0100, Cron Daemon wrote: r4742 | luigi | 2014-01-11 12:26:06 +0100 (Sat, 11 Jan 2014) | 1 line Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/parsettfatt.c unwanted side effects: font loading takes way longer due to linear checks and it makes no sense to do that for a bugged font; this can better be doen at the lua end if needed at all (hans) Then you are better dropping glyph name guessing code completely because it is known to produce duplicate glyph names, having generic glyph names is better than having more than one glyph with the same name (the fonts are not bugged, but the original was). Regards, Khaled ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Dear Khaled, since you were not included in the recent discussion I only wanted to briefly explain my part of the story of recent changes that took place in ConTeXt and in LuaTeX. They might be relevant for luaotfload as well, but if details are needed, Taco and Hans can probably explain better than I can. I first figured out that font database generation (which actually stores just the font name, filename and a few basic font properties, no actual info about glyphs or kerns or any other kind of huge data) took forever. I admit that I'm guilty of not having used the latest ConTeXt for a very long time already and in TL 2013 it behaved acceptable, so I only noticed it about a week or two ago (but many Mac users kept asking about ways to disable system fonts on the ConTeXt mailing list recently). I'm not sure how long that forever processing of LastResort.ttf was because I gave up after about half an hour, but it could have been 40-60 minutes or so (I think the font generation job actually finished once in the background). It turned out that something weird was going on with the font LastResort.ttf (which is also blacklisted in luaotfload, I think, based on some comments on stackexchange claiming that processing that font takes a very long time). Then both Hans and Taco fixed a few bits both in the LuaTeX engine and in ConTeXt. This reduced the time to deal with this font to about 4 seconds I think. Next I found out that extracting the name from Arial Unicode alone took about 30 seconds. Luigi and Hans objected that my computer was ultra-slow and that doing the same on their machines with SSD took 3 seconds. Hans sent me a minimal lua script to mimick the basic operations done in font generation database and it turned out that the slow part of the code was opening and closing the font when trying to extract a few parameters. And just opening the Arial font without doing anything else took that 30 seconds, while doing the same with TeX Live 2013 took just 0.15 seconds or so. Then Luigi figured out which commit was responsible for that enormous time waste and this is exactly the reverted commit. (I don't know what the proper way to deal with this is, but ending up with 30 seconds time to solely open the font seems like an overkill to me. I didn't try to understand the code, but I strongly suspect that an O(n^2) algorithm was used where an O(n) could be written if the reverted code still seems valuable/usable. I mean: glyphNameExists could easily be implemented with O(1) or O(log n), there's no need for O(n).) I was still dissatisfied with 2-3 minutes font database generation time, given that ConTeXt spent about 3-4 seconds per certain Korean fonts (Mac ships with 24 of those) and some others, so LuaTeX was further modified to provide a few extra bits of meta font information, so that ConTeXt no longer had to open any font to get sufficient information. All in all this lead to reduction of time spent on font generation database from (probably) 40-60 minutes to merely 3 seconds on my so-called old and slow notebook from 2009. I'm not sure who takes care of luaotfload, but I believe this is something worth fixing there as well. Mojca On Sun, Jan 12, 2014 at 11:51 PM, Khaled Hosny wrote: On Sat, Jan 11, 2014 at 04:30:19PM +0100, Cron Daemon wrote: r4742 | luigi | 2014-01-11 12:26:06 +0100 (Sat, 11 Jan 2014) | 1 line Changed paths: M /trunk/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/parsettfatt.c unwanted side effects: font loading takes way longer due to linear checks and it makes no sense to do that for a bugged font; this can better be doen at the lua end if needed at all (hans) Then you are better dropping glyph name guessing code completely because it is known to produce duplicate glyph names, having generic glyph names is better than having more than one glyph with the same name (the fonts are not bugged, but the original was). Regards, Khaled ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 04/27/2012 05:26 AM, Khaled Hosny wrote: Hi Taco, With this commit arbitrary number of top and/or bottom accents can be nested and still be positioned properly, so I think there is no need for `\Umathaccent both` anymore, so do you object if we deprecated it now, and later when it is completely removed math accent code can be simplified again (no need for separate field for bottom accents with all its complexity), what do you think? That sounds good. Best wishes, Taco ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 27-4-2012 05:26, Khaled Hosny wrote: Hi Taco, With this commit arbitrary number of top and/or bottom accents can be nested and still be positioned properly, so I think there is no need for `\Umathaccent both` anymore, so do you object if we deprecated it now, and later when it is completely removed math accent code can be simplified again (no need for separate field for bottom accents with all its complexity), what do you think? On Thu, Apr 26, 2012 at 10:28:29PM +0200, Cron Daemon wrote: r4371 | khaled | 2012-04-26 18:18:10 +0200 (Thu, 26 Apr 2012) | 5 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.w Properly position stacked math accents If the accentee is a |sub_math_list|, we check if it is composed of an |accent_noad| we use the positioning of its nucleus, up to the inner most |accent_noad|. it was introduced with a reason (also proabably inspired by mathml): with 'both' we only need to pick up the argument (math expression) once can you be a bit more explicit about removing the bottom option? how does one position at the bottom then (as Umathbotaccent was removed)? 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 - ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Fri, Apr 27, 2012 at 09:28:45AM +0200, Hans Hagen wrote:
On 27-4-2012 05:26, Khaled Hosny wrote:
Hi Taco,
With this commit arbitrary number of top and/or bottom accents can be
nested and still be positioned properly, so I think there is no need for
`\Umathaccent both` anymore, so do you object if we deprecated it now,
and later when it is completely removed math accent code can be
simplified again (no need for separate field for bottom accents with all
its complexity), what do you think?
On Thu, Apr 26, 2012 at 10:28:29PM +0200, Cron Daemon wrote:
r4371 | khaled | 2012-04-26 18:18:10 +0200 (Thu, 26 Apr 2012) | 5 lines
Changed paths:
M /trunk/source/texk/web2c/luatexdir/tex/mlist.w
Properly position stacked math accents
If the accentee is a |sub_math_list|, we check if it is composed of an
|accent_noad| we use the positioning of its nucleus, up to the inner
most |accent_noad|.
it was introduced with a reason (also proabably inspired by mathml):
with 'both' we only need to pick up the argument (math expression)
once
Not sure I understand this.
can you be a bit more explicit about removing the bottom option? how
does one position at the bottom then (as Umathbotaccent was
removed)?
Currently we have:
\Umathaccent top_accent accentee
\Umathaccent bottom bottom_accent accentee
\Umathaccent both top_accent accentee bottom_accent accentee
The only reason I see for having `both` is to be able to apply top and
bottom accents simultaneously and keep them properly positioned, but
with that commit we can nest any number of accents and they will be
properly positioned, i.e. the same effect can be achieved with:
\Umathaccent top_accent {\Umathaccent bottom bottom_accent accentee}
(the order of accents does not matter), so `both` is redundant and can
be removed and when removed we can simplify the implementation (with no
user visible change). Am I missing anything here?
Regards,
Khaled
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Fri, Apr 27, 2012 at 01:01:15PM +0200, Hans Hagen wrote:
One of the conceptual differences is
\def\xxx#1{...{#1}}
and
\def\xxx{...} % {#1} picked up by the scanner and not passed as argument
I see, though I don't think it justifies the complexity of the code, but
I can live with that.
a variant would be
\Umathaccent [bottom] accent [bottom] accent ... \relax accentee
i.e. keep reading specifications till an accentee or \relax is seen.
That wouldn't help my point in simplifying the implementation, so I'll
just keep the existing syntax.
Anyhow, we shouldn't discard functionality that was introduced for a
reason too fast,
That is why I'm asking :)
Regards,
Khaled
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Hi Taco, With this commit arbitrary number of top and/or bottom accents can be nested and still be positioned properly, so I think there is no need for `\Umathaccent both` anymore, so do you object if we deprecated it now, and later when it is completely removed math accent code can be simplified again (no need for separate field for bottom accents with all its complexity), what do you think? On Thu, Apr 26, 2012 at 10:28:29PM +0200, Cron Daemon wrote: r4371 | khaled | 2012-04-26 18:18:10 +0200 (Thu, 26 Apr 2012) | 5 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.w Properly position stacked math accents If the accentee is a |sub_math_list|, we check if it is composed of an |accent_noad| we use the positioning of its nucleus, up to the inner most |accent_noad|. Regards, Khaled ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 1-3-2012 00:18, Khaled Hosny wrote: On Wed, Feb 29, 2012 at 11:15:55PM +0100, Hans Hagen wrote: On 29-2-2012 22:43, Khaled Hosny wrote: On Wed, Feb 29, 2012 at 10:28:24PM +0100, Cron Daemon wrote: r4361 | khaled | 2012-02-29 20:13:40 +0100 (Wed, 29 Feb 2012) | 9 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.w Rewrite get_delim_box() The older version was always returning a box larger than requested and with some fonts (e.g. STIX Math) extensible \overbrace was too much wider than it should. I tried debugging it but it was too much complex doing many clever things. The rewrite is partly stolen from XeTeX one, further improved and is much simpler and had no regressions AFAICT. I hope this won't break anything (I tested as much as I can), I didn't want to make such invasive changes but this one was irresistible :) if it breaks old time bordercase misuse in macro solutions we should not bother too much (as long it's documented) It should improve things, no breakage is indented. LuaTeX's math code is a bit risky because there is no clear separation handling of old and new math fonts, I'd have liked of code for TFM fonts was separate and frozen, but I think it is too late for that. it is on the agenda to have a flag in the tfmtable for that so that there can be branches for each case so if the old code is commented out it can always be introduced again (unless we decide that luatex is opentype math machinery only, which is unlikely as till now we want to be old tex compatible 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 - ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Wed, Feb 29, 2012 at 11:15:55PM +0100, Hans Hagen wrote: On 29-2-2012 22:43, Khaled Hosny wrote: On Wed, Feb 29, 2012 at 10:28:24PM +0100, Cron Daemon wrote: r4361 | khaled | 2012-02-29 20:13:40 +0100 (Wed, 29 Feb 2012) | 9 lines Changed paths: M /trunk/source/texk/web2c/luatexdir/tex/mlist.w Rewrite get_delim_box() The older version was always returning a box larger than requested and with some fonts (e.g. STIX Math) extensible \overbrace was too much wider than it should. I tried debugging it but it was too much complex doing many clever things. The rewrite is partly stolen from XeTeX one, further improved and is much simpler and had no regressions AFAICT. I hope this won't break anything (I tested as much as I can), I didn't want to make such invasive changes but this one was irresistible :) if it breaks old time bordercase misuse in macro solutions we should not bother too much (as long it's documented) It should improve things, no breakage is indented. LuaTeX's math code is a bit risky because there is no clear separation handling of old and new math fonts, I'd have liked of code for TFM fonts was separate and frozen, but I think it is too late for that. Regards, Khaled ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
What about patterns, are they going to be case-sensitive, too? That could resolve one class of homonyms in German language, e.g., spie-len-de vs. Spiel-en-de Spielende can be hyphenated the first way if it starts at the beginning of the sentence: Spie-len-de Kinder sehe ich jeden Tag. Patrick ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Am 06.09.2010 10:54, schrieb Patrick Gundlach: What about patterns, are they going to be case-sensitive, too? That could resolve one class of homonyms in German language, e.g., spie-len-de vs. Spiel-en-de Spielende can be hyphenated the first way if it starts at the beginning of the sentence: Spie-len-de Kinder sehe ich jeden Tag. Ouch, didn't think about capitalisation at sentence beginning! As in German language every word can be at the beginning of a sentence, case-sensitive hyphenation would indeed introduce new errors (where there are clear rules what hyphenation to prefer for homonyms in our patterns currently). Case-sensitive hyphenation seems to need grammar analysis. Best regards, Stephan Hennig ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
2010/9/6 Stephan Hennig mailing_l...@arcor.de: Case-sensitive hyphenation seems to need grammar analysis. Seems like a problem best solved by iTeX. :-) Best Martin ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 09/05/2010 01:02 AM, Oudompheng Rémy wrote:
Cron Daemon wrote:
* it is now possible to add extra hyphenation points to a compound word
containing explict hyphens via a hyphenation exception
I do not quite understand this comment: what syntax is used to specify
hyphenation for the word pseudo-compatible for example ?
Please rtfm, it is not just my diary. Anyway:
\hyphenation{pseudo{-}{}{-}compa-tible}
Best wishes,
Taco
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Patrick Gundlach wrote:
[changes from svn/cron]
* hyphenation exceptions are now case sensitive
Does that mean that if I write
\hyphenation{man-u-script}
Manuscript will not be covered?
Yes, exactly. It seemed a reasonable thing to do,
considering that it is considerably easier to add another
exception than it is to prevent an unwanted hyphenation if it
is defined by an exception.
While I don't have an opinion at all on whether this is good or not, won't this
a) break TeX compatibility and b) will make existing documents (hyphenation
exceptions) fail ?
I am _not_ asking to change anything, I am just wondering and trying to
understand TeX.
Patrick
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 09/05/2010 02:55 PM, Patrick Gundlach wrote:
Patrick Gundlach wrote:
[changes from svn/cron]
* hyphenation exceptions are now case sensitive
Does that mean that if I write
\hyphenation{man-u-script}
Manuscript will not be covered?
Yes, exactly. It seemed a reasonable thing to do,
considering that it is considerably easier to add another
exception than it is to prevent an unwanted hyphenation if it
is defined by an exception.
While I don't have an opinion at all on whether this is good or not, won't this
a) break TeX compatibility and
Yeah, sure it does. But LuaTeX's language handling is already
incompatible in other ways, so that is not a big deal.
b) will make existing documents (hyphenation exceptions) fail ?
Yes, for example:
bla bla bla. Declination is
will not use the standard hyphen.tex exception for Declination.
Personally, I think this is acceptable. But if there are objections,
I can go back to being case-incensitive, it is not that important.
Best wishes,
Taco
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Sun, Sep 05, 2010 at 04:35:16PM +0200, Taco Hoekwater wrote:
On 09/05/2010 02:55 PM, Patrick Gundlach wrote:
Patrick Gundlach wrote:
[changes from svn/cron]
* hyphenation exceptions are now case sensitive
Does that mean that if I write
\hyphenation{man-u-script}
Manuscript will not be covered?
Yes, exactly. It seemed a reasonable thing to do,
considering that it is considerably easier to add another
exception than it is to prevent an unwanted hyphenation if it
is defined by an exception.
While I don't have an opinion at all on whether this is good or not, won't
this
a) break TeX compatibility and
Yeah, sure it does. But LuaTeX's language handling is already
incompatible in other ways, so that is not a big deal.
b) will make existing documents (hyphenation exceptions) fail ?
Yes, for example:
bla bla bla. Declination is
will not use the standard hyphen.tex exception for Declination.
Personally, I think this is acceptable. But if there are objections,
I can go back to being case-incensitive, it is not that important.
Since we are using different hyphenation patterns anyway (may be except
for English), then I think it is better to adapt hyphenation patterns, I
don't even see a reason for defaulting to Knuth's patterns for English,
since the output is likely to be different anyway.
Regards,
Khaled
--
Khaled Hosny
Arabic localiser and member of Arabeyes.org team
Free font developer
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Since we are using different hyphenation patterns anyway Not really, apart for German, for which patterns are being actively updated and tested. For most of the other languages we still use patterns that are sometimes several decades old, and not really maintained by anyone. The only difference between UTF-8 TeX engines and 8-bit engines is that for the latter ones, the patterns are converted to an appropriate 8-bit encoding on the fly, with the additional difference that LuaTeX can load patterns on demand during each run, but it still uses the same patterns. Arthur ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
[changes from svn/cron]
* hyphenation exceptions are now case sensitive
Does that mean that if I write
\hyphenation{man-u-script}
Manuscript will not be covered?
Patrick
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Patrick Gundlach wrote:
[changes from svn/cron]
* hyphenation exceptions are now case sensitive
Does that mean that if I write
\hyphenation{man-u-script}
Manuscript will not be covered?
Yes, exactly. It seemed a reasonable thing to do,
considering that it is considerably easier to add another
exception than it is to prevent an unwanted hyphenation if it
is defined by an exception.
Best wishes,
Taco
___
dev-luatex mailing list
dev-luatex@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Cron Daemon wrote: * it is now possible to add extra hyphenation points to a compound word containing explict hyphens via a hyphenation exception I do not quite understand this comment: what syntax is used to specify hyphenation for the word pseudo-compatible for example ? -- Rémy. ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Sun, Sep 05, 2010 at 01:02:44AM +0200, Oudompheng Rémy wrote: Cron Daemon wrote: * it is now possible to add extra hyphenation points to a compound word containing explict hyphens via a hyphenation exception I do not quite understand this comment: what syntax is used to specify hyphenation for the word pseudo-compatible for example ? I think it is explained in the manual (that was updated in that commit). (I really appreciate that LuaTeX has a reference manual right from the start, that is actively maintained and not an afterthought.) Regards, Khaled -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Sat, Aug 07, 2010 at 06:08:12PM +0200, Arthur Reutenauer wrote: apply the memory leak patch from bug report #463 (from R?\195?\169my Oudompheng) Poor Rémy... ;-) It's a shame Subversion screws up the encoding so badly! Not subversion, but whatever tool that sends the email notifications. -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Not subversion, but whatever tool that sends the email notifications. Funny, I've seen Subversion doing exactly that when I was working in UTF-8 locale (it quotes the individual bytes in non-ASCII characters in decimal, and inserts a question mark before each escape sequence). But here the character is indeed correctly encoded in latin-1. Arthur ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Sat, Aug 07, 2010 at 08:06:51PM +0200, Arthur Reutenauer wrote: Not subversion, but whatever tool that sends the email notifications. Funny, I've seen Subversion doing exactly that when I was working in UTF-8 locale (it quotes the individual bytes in non-ASCII characters in decimal, and inserts a question mark before each escape sequence). But here the character is indeed correctly encoded in latin-1. I just did git svn rebase and I got the log message correctly, I've long been using svn with log messages containing Arabic with no problem at all, only mail notifications are broken. -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On Sat, Jul 31, 2010 at 08:28:15AM +0200, Taco Hoekwater wrote: On 07/31/2010 12:38 AM, Martin Schröder wrote: 2010/7/31 Hans Hagenpra...@wxs.nl: On 30-7-2010 10:27, Cron Daemon wrote: no more xpdf afaik ... derived from xpdf Yes. :-) In fact, this would have been a _whole- lot harder if it wasn't. But still Martin, and I deleted all the 'xpdf' words from the luatex build system. :-) The credits still have xpdf by Derek Noonburg (partial), but no similar line for poppler (though there is a Compiled with poppler). -- Khaled Hosny Arabic localiser and member of Arabeyes.org team Free font developer ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 07/31/2010 12:34 PM, Khaled Hosny wrote: On Sat, Jul 31, 2010 at 08:28:15AM +0200, Taco Hoekwater wrote: On 07/31/2010 12:38 AM, Martin Schröder wrote: 2010/7/31 Hans Hagenpra...@wxs.nl: On 30-7-2010 10:27, Cron Daemon wrote: no more xpdf afaik ... derived from xpdf Yes. :-) In fact, this would have been a _whole- lot harder if it wasn't. But still Martin, and I deleted all the 'xpdf' words from the luatex build system. :-) The credits still have xpdf by Derek Noonburg (partial), but no similar line for poppler (though there is a Compiled with poppler). Yes, and the manual still needs updating as well. Best wishes, Taco ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 30-7-2010 10:27, Cron Daemon wrote: no more xpdf afaik ... derived from xpdf 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 - ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
2010/7/31 Hans Hagen pra...@wxs.nl: On 30-7-2010 10:27, Cron Daemon wrote: no more xpdf afaik ... derived from xpdf Yes. :-) Best Martin ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
2010/3/6 Taco Hoekwater t...@elvenkind.com: [t...@ntg devel]$ svn up svn: Server sent unexpected return value (405 Method Not Allowed) in response to PROPFIND request for '/svn/metapost/branches/devel' Works here (again?). LANG=C svn info . Path: . URL: http://scm.foundry.supelec.fr/svn/luatex/trunk Repository Root: http://scm.foundry.supelec.fr/svn/luatex Repository UUID: 0b2b3880-5936-4365-a048-eb17d2e5a6bf Revision: 3455 Node Kind: directory Schedule: normal Last Changed Author: taco Last Changed Rev: 3455 Last Changed Date: 2010-03-05 14:48:25 +0100 (Fri, 05 Mar 2010) Best Martin ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
On 6 March 2010 Taco Hoekwater wrote: Is what we get from svn co, and svn up gives: [t...@ntg devel]$ svn up svn: Server sent unexpected return value (405 Method Not Allowed) in response to PROPFIND request for '/svn/metapost/branches/devel' I get $ svn up [...stuff omitted...] Updated to revision 3455. and svn co http://foundry.supelec.fr/svn/luatex obviously works too (though I aborted the download in order to avoid unnecessary network traffic). Maybe it's sufficient to try again. Regards, Reinhard -- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotu...@web.de Microsoft isn't the answer. Microsoft is the question, and the answer is NO. ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Cron Daemon wrote: svn: OPTIONS of 'http://foundry.supelec.fr/svn/luatex': Could not resolve hostname `foundry.supelec.fr': Temporary failure in name resolution (http://foundry.supelec.fr) I've turned this cron job off until my coworker and me can figure out what is wrong with our dns routing. Best wishes, Taco ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
Re: [Dev-luatex] Cron luatex@boekplan /var/www/luatex.org/www/bin/luatex-svn
Vafa Khalighi wrote: On Fri, Jan 1, 2010 at 2:25 AM, Cron Daemon r...@mail.boekplan.nl wrote: svn: OPTIONS of 'http://foundry.supelec.fr/svn/luatex': could not connect to server (http://foundry.supelec.fr) Well, the server is down (that much should be obvious). These messages will stop as soon as it comes online again. Best wishes, Taco ___ dev-luatex mailing list dev-luatex@ntg.nl http://www.ntg.nl/mailman/listinfo/dev-luatex
