newlines
Mojca Miklavec
I spotted one of the places which costed me some gray hair:
[ mswin=>\edef\@@svline{\rawcharacter{13}},
% cr % crlf
(line 84 in cont-sys.tex).
When I changed 13 to 10, it worked 300% better. I'm trying to figure
out what's going on here since there might be quite some mechanisms
interfering with each other (redefinition of the original newline or
setting newline multiple times).
I spotted that when I noticed that the gnuplot module worked OK with
MikTeX, but failed with the standalone distribution. When running
under MikTeX, it seems that ConTeXt isn't aware that it's being run
under "mswin". and consequently behaves much better with respect to
newlines than the standalone distr.
I was totally confused since I was sure that the module worked already
but failed under any circumstances with just any version of the
gnuplot module. Apparently the successful run was an accidental usage
of MikTeX. (From time to time I'm thankful that I have both installed.
:)
I can also point out that all those metapost graphics contain a whole
lot of "13"s (seen as ^M in the editor). The funny thing is that if I
set
\rawcharacter{13}\rawcharacter{10}
then I get "13,13,10" as a newline (half-wrong, one "13" too much, but
works OK), if I set
\rawcharacter{10}
then I get "13,10" as a new line (which is what it's supposed to be)
and if I set
\rawcharacter{13}
then I get only "13" which is complety wrong and doesn't work with the module.
For now I've changed it to 10 locally, since I can't work otherwise,
but for the distribution it would be necessary to test it a bit and to
change it at least somehow. It would also be necessary to figure out
how to trick MikTeX to set the "mswin" variable properly.
Mojca
Mojca Miklavec
> Hello, Hans,
>
> I spotted one of the places which costed me some gray hair:
>
> [ mswin=>\edef\@@svline{\rawcharacter{13}},
And even more weird things are happening now. I was observing the
*-mpgraph.mp files now that I've changed the option from 13 to 10.
Some files have only "13" and some have "10,13" as line endings. I
don't understand anything any more. Does it depend on wheather
perhaps? ;)
But the good news is that line endings in gnuplot scripts now finally
work without any problem even without having to mimic \obeyMPlines ;)
(I'll test with XeTeX later - I don't won't to spoil my good mood now ;)
Mojca
Taco Hoekwater
> When I changed 13 to 10, it worked 300% better. I'm trying to figure
> out what's going on here since there might be quite some mechanisms
> interfering with each other (redefinition of the original newline or
> setting newline multiple times).
If TeX sees a character that matches the current code of \newlinechar
during a write, then it will use to the systems "new line" construct
instead of that character (the result can be CR of LF or CRLF or
perhaps even more exotic). If the system messes this up, then it is
a bug in the TeX implementation.
In ConTeXt (as in plain), \newlinechar is normally minus one, so
TeX's conversion does not take place. The system C library (like on
Windows) may decide that it will convert LF to CRLF because the file
is opened in 'text' mode, for instance. This behaviour is
implementation dependent as it is part of the allowed differences
between TeX implementations.
IMHO, the default \newlinechar -1 was a mistake. Why invent a
portable line ending solution first, then not actually use it.
Cheers,
Taco
Mojca Miklavec
I didn't quite understand the answer.
What should go into \systemendofline in your opinion then? (I can
still redefine it in the module to the value of 10 to make sure that
it will work on windows, on linux it's set to 10 already.)
Thanks,
Mojca
Taco Hoekwater
Mojca Miklavec wrote:
>
> What should go into \systemendofline in your opinion then? (I can
> still redefine it in the module to the value of 10 to make sure that
> it will work on windows, on linux it's set to 10 already.)
I propose setting them all to the same value (say 10), and
setting \newlinechar to 10 as well.
Taco