Just like in luatex 0.79.1, log files are 1 character too wide. They should be 79 characters, plus an EOL = 80 characters. Please compare the two log files for this source:
Hello\bye
On 5/20/2015 12:04 AM, Wybo Dekker wrote:
Just like in luatex 0.79.1, log files are 1 character too wide. They should be 79 characters, plus an EOL = 80 characters.
Consider eol a separator (could as well would be cr+lf on windows).
Please compare the two log files for this source:
One can adapt the configuration files for luatex to be one char less than default if needed. (Fwiw: context sets up lines to be 1000 in length.)
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 -----------------------------------------------------------------
On 2015-05-20 01:23, Hans Hagen wrote:
On 5/20/2015 12:04 AM, Wybo Dekker wrote:
Just like in luatex 0.79.1, log files are 1 character too wide. They should be 79 characters, plus an EOL = 80 characters.
Consider eol a separator (could as well would be cr+lf on windows).
Please compare the two log files for this source:
One can adapt the configuration files for luatex to be one char less than default if needed. (Fwiw: context sets up lines to be 1000 in length.)
What configuration file(s) are you talking about? The one I know is texmf.cnf, which sets max_print_line to 79, for all engines. You can change that, of course, but luatex will always use one character more than the other engines.
Even worse: the \message command obeys the max_print_line setting, while luatex takes one character more. As a result, the log file becomes unparsable, having different maximum line lengths in one file. See the attached source and the pdftex (lines 7&8)/luatex (lines 5&6) logs.
As for the modernization of log files you talked about off the record: It would be really modern to not impose any maximum line length by set setting max_line_length to, say, 1e9. And to do that for all engines, not just luatex.
On 5/20/2015 12:59 PM, Wybo Dekker wrote:
As for the modernization of log files you talked about off the record: It would be really modern to not impose any maximum line length by set setting max_line_length to, say, 1e9. And to do that for all engines, not just luatex.
The other engines are more frozen than luatex; although we aim at tex engine compatibility (and achieve extensibility via callbacks) this is not true for the system dependent properties as i/o (and of course one can just stick to using pdftex or use xetex as wide engine).
(Concerning parsing logs: as the cnf is under user control you cannot assume that the log lines are the same always, as some users can set them different; i always did. So log file parsers should be flexible in this respect.)
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 -----------------------------------------------------------------
On 2015-05-20 15:41, Hans Hagen wrote:
On 5/20/2015 12:59 PM, Wybo Dekker wrote:
As for the modernization of log files you talked about off the record: It would be really modern to not impose any maximum line length by set setting max_line_length to, say, 1e9. And to do that for all engines, not just luatex.
The other engines are more frozen than luatex; although we aim at tex engine compatibility (and achieve extensibility via callbacks) this is not true for the system dependent properties as i/o (and of course one can just stick to using pdftex or use xetex as wide engine).
Of course; maybe even better, for stability and predictability, stick to LibreOffice or MS-Word. You don't even touch my question (which conffile(s)) and my arguments (unequal max lengths in one file, 80 is not 79). I now begin to understand the communication disorders between some TeX communities.
(Concerning parsing logs: as the cnf is under user control you cannot assume that the log lines are the same always, as some users can set them different; i always did. So log file parsers should be flexible in this respect.)
Am Wed, 20 May 2015 16:13:44 +0200 schrieb Wybo Dekker:
You don't even touch my question (which conffile(s))
You can change the line length in a texmf.cnf only for lualatex like this:
max_print_line = 79 max_print_line.lualatex = 78
I didn't try to find out how to do it permanently in miktex, but there it is possible to use a command line option
pdflatex -max-print-line=100 test-utf8
and my arguments (unequal max lengths in one file, 80 is not 79).
But Hans told you: luatex doesn't try to produce the same messages/logs as pdftex.
I also don't understand what you would gain if they were identical by default: as users can change them to their liking you can't rely on the values.
On 2015-05-20 16:58, Ulrike Fischer wrote:
Am Wed, 20 May 2015 16:13:44 +0200 schrieb Wybo Dekker:
You don't even touch my question (which conffile(s))
You can change the line length in a texmf.cnf only for lualatex like this:
max_print_line = 79 max_print_line.lualatex = 78
that would be an attempt to repair a luatex bug in texmf.cnf
I didn't try to find out how to do it permanently in miktex, but there it is possible to use a command line option
pdflatex -max-print-line=100 test-utf8
and my arguments (unequal max lengths in one file, 80 is not 79).
But Hans told you: luatex doesn't try to produce the same messages/logs as pdftex.
I don't ask for identical log files. I only ask for luatex to obey the max_print_line = 79 statement in texmf.cnf.
I also don't understand what you would gain if they were identical by default: as users can change them to their liking you can't rely on the values.
On 5/20/2015 11:49 PM, Wybo Dekker wrote:
On 2015-05-20 16:58, Ulrike Fischer wrote:
Am Wed, 20 May 2015 16:13:44 +0200 schrieb Wybo Dekker:
You don't even touch my question (which conffile(s))
You can change the line length in a texmf.cnf only for lualatex like this:
max_print_line = 79 max_print_line.lualatex = 78
that would be an attempt to repair a luatex bug in texmf.cnf
I didn't try to find out how to do it permanently in miktex, but there it is possible to use a command line option
pdflatex -max-print-line=100 test-utf8
and my arguments (unequal max lengths in one file, 80 is not 79).
But Hans told you: luatex doesn't try to produce the same messages/logs as pdftex.
I don't ask for identical log files. I only ask for luatex to obey the max_print_line = 79 statement in texmf.cnf.
as texlive 2015 and therefore 0,80 stable is frozen that won't help you and by the time we have a new release we might as well have dropped the length check (and have long lines)
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 -----------------------------------------------------------------
On 2015-05-21 00:39, Hans Hagen wrote:
I don't ask for identical log files. I only ask for luatex to obey the
max_print_line = 79 statement in texmf.cnf.
as texlive 2015 and therefore 0,80 stable is frozen that won't help you and by the time we have a new release we might as well have dropped the length check (and have long lines)
If it's only in TeXLive that new versions of luatex appear, I'll be happy to wait for another year.
On Thu, May 21, 2015 at 11:09 AM, Wybo Dekker wybo@dekkerdocumenten.nl wrote:
On 2015-05-21 00:39, Hans Hagen wrote:
I don't ask for identical log files. I only ask for luatex to obey the
max_print_line = 79 statement in texmf.cnf.
as texlive 2015 and therefore 0,80 stable is frozen that won't help you and by the time we have a new release we might as well have dropped the length check (and have long lines)
If it's only in TeXLive that new versions of luatex appear, I'll be happy to wait for another year.
I will see it tomorrow.
Hans Hagen pragma@wxs.nl writes:
(Concerning parsing logs: as the cnf is under user control you cannot assume that the log lines are the same always, as some users can set them different; i always did. So log file parsers should be flexible in this respect.)
Standard TeX is the most fun in that respect. It wraps after 79 bytes, never mind whether you are in the middle of a UTF-8 character or not.
That's sort of ugly to process with a UTF-8-aware system.
On Wed, May 20, 2015 at 4:15 PM, David Kastrup dak@gnu.org wrote:
Hans Hagen pragma@wxs.nl writes:
(Concerning parsing logs: as the cnf is under user control you cannot assume that the log lines are the same always, as some users can set them different; i always did. So log file parsers should be flexible in this respect.)
Standard TeX is the most fun in that respect. It wraps after 79 bytes, never mind whether you are in the middle of a UTF-8 character or not.
That's sort of ugly to process with a UTF-8-aware system.
infact I see different output in pdftex luatex and xetex:
Hello\message{% 1xxxxxxxxxx% 2xxxxxxxxx% 3xxxxxxxxx% 4xxxxxxxxx% 5xxxxxxxxx% 6xxxxxxxxx% 7xxxxxxxxx% 8xxxxxx鹿xx% 9xxxxxxxxx% 10xxxxxxxx% 11xxxxxxxx% 12xxxxxxxx% 13xxxxxxxx% 14xxxxxxxx% 15xxxxxxxx% 16xxxxxxxx% } \bye
xetex and luatex correctly display 鹿 but luatex has this off-by-one "bug" that I still have to catch.
On Wed, May 27, 2015 at 12:21 PM, luigi scarso luigi.scarso@gmail.com wrote:
On Wed, May 20, 2015 at 4:15 PM, David Kastrup dak@gnu.org wrote:
Hans Hagen pragma@wxs.nl writes:
(Concerning parsing logs: as the cnf is under user control you cannot assume that the log lines are the same always, as some users can set them different; i always did. So log file parsers should be flexible in this respect.)
Standard TeX is the most fun in that respect. It wraps after 79 bytes, never mind whether you are in the middle of a UTF-8 character or not.
That's sort of ugly to process with a UTF-8-aware system.
infact I see different output in pdftex luatex and xetex:
Hello\message{% 1xxxxxxxxxx% 2xxxxxxxxx% 3xxxxxxxxx% 4xxxxxxxxx% 5xxxxxxxxx% 6xxxxxxxxx% 7xxxxxxxxx% 8xxxxxx鹿xx% 9xxxxxxxxx% 10xxxxxxxx% 11xxxxxxxx% 12xxxxxxxx% 13xxxxxxxx% 14xxxxxxxx% 15xxxxxxxx% 16xxxxxxxx% } \bye
xetex and luatex correctly display 鹿 but luatex has this off-by-one "bug" that I still have to catch. -- luigi
Ok, not a bug. 0) xetex and luatex don't break a utf-8 sequence (or better, at least luatex should not break an utf-8 sequence in output); 1) xetex show 79 (ie. max_print_line) unicode chars in a utf-8 encoding, so in this case we have that the line with 鹿 is longer than 79 bytes; 2) luatex always shows at max 79 bytes, so in this case that line is shorter .
So an applications that expect at max 79 bytes is ok with luatex, as also is ok an application that expect a valid utf-8 line that ends with "\n" .
On 5/20/2015 12:59 PM, Wybo Dekker wrote:
Even worse: the \message command obeys the max_print_line setting, while luatex takes one character more. As a result, the log file becomes unparsable, having different maximum line lengths in one file. See the attached source and the pdftex (lines 7&8)/luatex (lines 5&6) logs.
The log/term interface is a complex one (also because it has to deal with tex as well as lua output) and will be redone at some point so even if we would 'fix' it (whatever that means esp with respect to utf as David points out) there is good change that a future version would be different. Most likely is that the length check will go away completely as it's not needed today.
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 -----------------------------------------------------------------
-
David Kastrup -
Hans Hagen -
luigi scarso -
Ulrike Fischer -
Wybo Dekker