Re: [XeTeX] xetex installation

[Zdenek Wagner]

And if you do not know which font file to send me, this is a help:

$ fc-match -v lohitbengali
Pattern has 31 elts (size 32)
family: "Lohit Bengali"(s)
familylang: "en"(s)
style: "Regular"(w)
stylelang: "en"(w)
fullname: "Lohit Bengali"(w)
fullnamelang: "en"(w)
slant: 0(i)(s)
weight: 80(i)(s)
width: 100(i)(s)
size: 12(f)(s)
pixelsize: 12.5(f)(s)
foundry: "unknown"(s)
hintstyle: 3(i)(s)
hinting: FcTrue(s)
verticallayout: FcFalse(s)
autohint: FcTrue(w)
globaladvance: FcTrue(s)
file: "/usr/share/fonts/lohit-bengali/Lohit-Bengali.ttf"(s)
index: 0(i)(s)
outline: FcTrue(s)
scalable: FcTrue(s)
dpi: 75(f)(s)
scale: 1(f)(s)
charset:
:   f801 7801  0004
0080 0080
0009:    0030 fff99fee f3c5fdff
b080799f 0fcf
0020: 33183000 0040    0200
 
0022: 0004     
 
0025:      
1000 
(s)
lang: as|bn|mni(s)
fontversion: 163840(i)(s)
capability: "otlayout:beng"(s)
fontformat: "TrueType"(s)
embeddedbitmap: FcTrue(s)
decorative: FcFalse(s)
namelang: "en"(s)

Notice that fc-match tries to find similar names if the exact match is not
found. It says that the correct font name is Lohit Bengali and the
corresponding file is
/usr/share/fonts/lohit-bengali/Lohit-Bengali.ttf


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 21:11 GMT+01:00 Zdenek Wagner :

> If it is a font issue, TeX Live 2015 will not help but downgrade to 2012
> will. I still have all versions from 2007 to 2015 installed. If I get a
> short text demonstrating complex conjuncts and your font file, I can test
> it in all TL versions both with your font and my fonts.
>
> Zdeněk Wagner
> http://ttsm.icpf.cas.cz/team/wagner.shtml
> http://icebearsoft.euweb.cz
>
> 2016-03-13 19:40 GMT+01:00 Susan Dittmar :
>
>> Hi!
>>
>> Purnendu Chakraborty schrieb:
>>
>>> I have a naive question to the group. How do I set up xetex distribution
>>> in the
>>> user area?  I could not find any documentation in this regard.
>>>
>>> The reason is the following. I have TeXlive 2013 from  Opensuse 13.2. I
>>> find
>>> that the xetex bundled with distribution is buggy. I have some issue
>>> with Bengali
>>> conjuncts with this version of xetex.  So I want a fresh install of
>>> xetex without
>>> touching the system-wide TexLive installation.
>>>
>>
>> If you have enough room on the disk -- my installation takes about 4.3 G
>> -- you can easily install the current texlive (which includes xetex) in
>> your home directory. Just download the installation script, start it as
>> instructed, and before you tell it to install, change the directories
>> appropriately. Then write a small script that adds the paths to your
>> current environment. Something like
>>
>> -- texlive2015.sh --
>> #!/bin/bash
>> export INFOPATH="~/texlive/2015/texmf-dist/doc/info:${INFOPATH}"
>> export  MANPATH="~/texlive/2015/texmf-dist/doc/man:${MANPATH}"
>> export PATH="~/texlive/2015/bin/x86_64-linux:${PATH}"
>> -- end of texlive2015.sh --
>>
>> You might have to adjust the paths. Now, before you use xetex, call this
>> script, for example
>>
>> . texlive2015.sh
>>
>> from the same shell (terminal) from which you call your XeTeX-using
>> programms.
>>
>> This precedes the given paths with the new version paths, so any program
>> you call with these environment variables active is searched for in the new
>> directories first.
>>
>> If you know you'll never want to use openSUSE's version of texlive 2013,
>> you can rename this file to '~/.profile' (make sure such a file does not
>> yet exist) or append those commands to an existing ~/.profile file. Then
>> you can even use (graphical) window manager shortcuts to TeX editors (in
>> case you use them) with the correct environment settings.
>>
>> Hope that helps,
>>
>> Susan
>>
>>
>>
>> --
>> Subscriptions, Archive, and List information, etc.:
>>  http://tug.org/mailman/listinfo/xetex
>>
>
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX Digest, Vol 144, Issue 15

[Philip Taylor]

Zdeněk Wagner wrote:

> Someone with better memory than me may probably help. Up to 2012 XeTeX
> used ICU, since 2013 it uses HarfBuzz. Some Indic fonts do not implement
> all features and thus they work with ICU, not with HarfBuzz. There is a
> feature that forces XeTeX to use ICU but I forgot it and cannot find it.

⟨Font options⟩ are only applicable when the font is selected through the
operating system (i.e., without square brackets). They may be any
concatenation of the following:
[...]
/ICU Explicitly use the OpenType renderer (deprecated since 0.).

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX Digest, Vol 144, Issue 15

[Zdenek Wagner]

Someone with better memory than me may probably help. Up to 2012 XeTeX used
ICU, since 2013 it uses HarfBuzz. Some Indic fonts do not implement all
features and thus they work with ICU, not with HarfBuzz. There is a feature
that forces XeTeX to use ICU but I forgot it and cannot find it. (gedit
uses Pango for rendering)

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 18:57 GMT+01:00 Purnendu Chakraborty <
purnendu.chakrabo...@gmail.com>:

> >
> > Most probably this is not a problem of xetex but a problem of the font.
> > Have you tried to use a different Bengali font? I do not know Bengali
> but I
> > use Devanagari frequently since XeTeX was compiled in TeX Live and I do
> not
> > have problems. Many years ago there were problems with FreeFont but these
> > bugs were fixed many years ago.
> >
> > Zden?k Wagner
>
>
> I have tried using different fonts and the problem persists. I had
> some Bengali documents
> which worked fine with an older installation of TeXLive.  The problem
> appeared once I
> upgraded my distribution. Also I tried some standard TeX documents,
> compiled successfully by others
> in different system and I know how the output looks like.  Thus I
> ruled out font problems.
> Bengali text  looks alright when I write it in gedit or any other word
> processor.
> Please let me also tell you that not all the conjuncts appear messy
> but only two of them.
>
> Regards,
> Purnendu
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xetex installation

[Susan Dittmar]

Hi!

Purnendu Chakraborty schrieb:

I have a naive question to the group. How do I set up xetex distribution in the
user area?  I could not find any documentation in this regard.

The reason is the following. I have TeXlive 2013 from  Opensuse 13.2. I find
that the xetex bundled with distribution is buggy. I have some issue
with Bengali
conjuncts with this version of xetex.  So I want a fresh install of
xetex without
touching the system-wide TexLive installation.


If you have enough room on the disk -- my installation takes about 4.3 G -- you 
can easily install the current texlive (which includes xetex) in your home 
directory. Just download the installation script, start it as instructed, and 
before you tell it to install, change the directories appropriately. Then write 
a small script that adds the paths to your current environment. Something like


-- texlive2015.sh --
#!/bin/bash
export INFOPATH="~/texlive/2015/texmf-dist/doc/info:${INFOPATH}"
export  MANPATH="~/texlive/2015/texmf-dist/doc/man:${MANPATH}"
export PATH="~/texlive/2015/bin/x86_64-linux:${PATH}"
-- end of texlive2015.sh --

You might have to adjust the paths. Now, before you use xetex, call this script, 
for example


. texlive2015.sh

from the same shell (terminal) from which you call your XeTeX-using programms.

This precedes the given paths with the new version paths, so any program you 
call with these environment variables active is searched for in the new 
directories first.


If you know you'll never want to use openSUSE's version of texlive 2013, you can 
rename this file to '~/.profile' (make sure such a file does not yet exist) or 
append those commands to an existing ~/.profile file. Then you can even use 
(graphical) window manager shortcuts to TeX editors (in case you use them) with 
the correct environment settings.


Hope that helps,

Susan


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xetex installation

[maxwell]

On 3/13/2016 1:57 PM, Purnendu Chakraborty wrote:

I have tried using different fonts and the problem persists. I had
some Bengali documents which worked fine with an older installation
of TeXLive.  The problem appeared once I upgraded my distribution.
Also I tried some standard TeX documents, compiled successfully by
others in different system and I know how the output looks like.
Thus I ruled out font problems. Bengali text  looks alright when I
write it in gedit or any other word processor. Please let me also
tell you that not all the conjuncts appear messy but only two of
them.


Then probably the right thing is to create a minimal example which 
contains a few conjuncts (those that don't work, plus a sample of those 
that do).  Then attach the source code for that minimal example--should 
be 10-20 lines at most--to an email to this list.  That's assuming the 
font is free, otherwise it will be difficult for people on this list to 
reproduce the problem.


Given that most of us don't know Bangla, it might also be necessary to 
attach a PDF of the output you got, and maybe also a PDF of the correct 
output (what you get with a word processor).


Note: I have restored Purnendu's original subject line, which got 
changed to "XeTeX Digest..." in the last reply.

--
Mike Maxwell
maxw...@umiacs.umd.edu
"I cannot believe that our existence in this universe
is a mere quirk of fate, an accident of history, an
incidental blip in the great cosmic drama. Our
involvement is too intimate. The physical species
Homo may count for nothing, but the existence of
mind in some organism on some planet in the universe
is surely a fact of fundamental significance. Through
conscious beings the universe has generated
self-awareness." --Paul Davies


--
Subscriptions, Archive, and List information, etc.:
 http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] XeTeX Digest, Vol 144, Issue 15

[Purnendu Chakraborty]

>
> Most probably this is not a problem of xetex but a problem of the font.
> Have you tried to use a different Bengali font? I do not know Bengali but I
> use Devanagari frequently since XeTeX was compiled in TeX Live and I do not
> have problems. Many years ago there were problems with FreeFont but these
> bugs were fixed many years ago.
>
> Zden?k Wagner


I have tried using different fonts and the problem persists. I had
some Bengali documents
which worked fine with an older installation of TeXLive.  The problem
appeared once I
upgraded my distribution. Also I tried some standard TeX documents,
compiled successfully by others
in different system and I know how the output looks like.  Thus I
ruled out font problems.
Bengali text  looks alright when I write it in gedit or any other word
processor.
Please let me also tell you that not all the conjuncts appear messy
but only two of them.

Regards,
Purnendu


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Zdenek Wagner wrote:

> In the very same way as TeX is called. It has to start a shell (cmd.exe
> in Windows) and ask it to start the lua interpreter and execute the lua
> script. If you want to analyze the log file immediatelly, I would write
> a lua script that would run tex, then looked into the log file and then
> generate an output and/or status code for the front end. The script
> would know the TeX command and the file name, hence it would know the
> name of the log file. You can invent command lines parameters for the
> script itself so that you can ask it to extract various pieces of
> information from the log to the console. One of my scripts extracts
> information on all overful \hboxes and the underful \hbox with the
> greatest badness.

Well, the TeXworks list has been copied into most (but not all) of this
thread, so I think it better if I allow Stefan to respond for himself.
My belief remains unchanged -- it is the engines that should be
enhanced, rather than the front ends, but in such a way that their
current behaviour is unaltered (e.g., a new command-line parameter).

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Zdenek Wagner]

2016-03-13 18:34 GMT+01:00 Philip Taylor :

>
>
> Zdenek Wagner wrote:
>
> > In MS-DOS, Windows, and OS/2 the script interpreter is recognized by a
> > file extension.
>
> Er, yes; but does that help ?  Does that in any way allow (say) TeXworks
> to use a script written in Lua, if its own internal scripting language
> is other than Lua ?
>

In the very same way as TeX is called. It has to start a shell (cmd.exe in
Windows) and ask it to start the lua interpreter and execute the lua
script. If you want to analyze the log file immediatelly, I would write a
lua script that would run tex, then looked into the log file and then
generate an output and/or status code for the front end. The script would
know the TeX command and the file name, hence it would know the name of the
log file. You can invent command lines parameters for the script itself so
that you can ask it to extract various pieces of information from the log
to the console. One of my scripts extracts information on all overful
\hboxes and the underful \hbox with the greatest badness.



Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Zdenek Wagner wrote:

> In MS-DOS, Windows, and OS/2 the script interpreter is recognized by a
> file extension.

Er, yes; but does that help ?  Does that in any way allow (say) TeXworks
to use a script written in Lua, if its own internal scripting language
is other than Lua ?


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

msk...@ansuz.sooke.bc.ca wrote:

> If a script begins with the characters "#!" and the name of a script
> interpreter, and has the execute bit set, then it can be executed like any
> other program, and the front end can run it the same way the front end
> would run any TeX engine.  This is a facility of the operating system,
> often called the "shebang" mechanism, and it is transparent to
> applications.  There is no need for the front end to know what language
> the script is written in, nor how to interpret that language.

As far as I am aware, Mathew, #! is meaningless to the Windows
command-line interpreter; I /believe/ (but have no first-hand knowledge
or experience) that its use is restricted to Unix-like systems.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[mskala]

On Sun, 13 Mar 2016, Philip Taylor wrote:
> > Nowadays all TeX distros have lua.
>
> The fact that a distribution may have (and include) a particular
> scripting language does not mean that a front-end such as TeXworks can
> necessarily make use of scripts expressed in that language, surely ?

It does.

If a script begins with the characters "#!" and the name of a script
interpreter, and has the execute bit set, then it can be executed like any
other program, and the front end can run it the same way the front end
would run any TeX engine.  This is a facility of the operating system,
often called the "shebang" mechanism, and it is transparent to
applications.  There is no need for the front end to know what language
the script is written in, nor how to interpret that language.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Zdenek Wagner wrote:

> Then there would need to be a further extension that would allow any
> package to signal a warning which could be handled in the same way.
> 
> 
> In other words, a new TeX primitive will have to be added.

Yes, that is what I meant by "a further extension".

> Nowadays all TeX distros have lua.

The fact that a distribution may have (and include) a particular
scripting language does not mean that a front-end such as TeXworks can
necessarily make use of scripts expressed in that language, surely ?

> I can imagine the following problems:
> Overful \hbox
> Overful \vbox
> Underful \hbox
> Uverful \vbox
> Undefined label
> Duplicate label
> Labels have changed
> Undefined citation
> Duplicate citation
> Missing character in a font
> 
> Now suppose that the document contains 5 overful hboxes, 12 underful
> hboxes, 4 underful vboxes, 3 undefined labels, 1 duplicate labes,
> changed labels, 153 missing citation, 52 missing characters. What status
> should be returned so that I could get this information without looking
> into the log file? (Yes/No answer might be sufficient without giving the
> exact numbers.)

--return-non-zero-status-on="all"

would return a non-zero status if any of the TeX warnings (not LaTeX
warnings concerning labels, citations, etc) were generated, which would
enable the front end (TeXworks, or any other) to determine that the
console should not be hidden since it contains important diagnostics.
That is all I am asking for, nothing as sophisticated as you suggest above.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] xetex installation

[Zdenek Wagner]

Most probably this is not a problem of xetex but a problem of the font.
Have you tried to use a different Bengali font? I do not know Bengali but I
use Devanagari frequently since XeTeX was compiled in TeX Live and I do not
have problems. Many years ago there were problems with FreeFont but these
bugs were fixed many years ago.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 17:57 GMT+01:00 Purnendu Chakraborty <
purnendu.chakrabo...@gmail.com>:

> I have a naive question to the group. How do I set up xetex distribution
> in the
> user area?  I could not find any documentation in this regard.
>
> The reason is the following. I have TeXlive 2013 from  Opensuse 13.2. I
> find
> that the xetex bundled with distribution is buggy. I have some issue
> with Bengali
> conjuncts with this version of xetex.  So I want a fresh install of
> xetex without
> touching the system-wide TexLive installation.
>
> Thanks,
> Purnendu
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Zdenek Wagner]

2016-03-13 17:41 GMT+01:00 Philip Taylor :

>
>
> Julian Bradfield wrote:
>
> > Do you have a full list of all possible now-and-future events that
> > you might want to flag this way?
>
> Yes. Anything/everything for which TeX issues a warning, either to the
> log file or to the console or both. The TeX source code is so modular
> and so well structured that it should be relatively easy to identify
> what warnings can be issued.
>
> > What about LaTeX/Plain TeX/AMSTeX warnings? They can be equally
> > important, but I don't think the core *TeX engine knows about them.
>
> Then there would need to be a further extension that would allow any
> package to signal a warning which could be handled in the same way.
>

In other words, a new TeX primitive will have to be added.

>
> > Just wrap *TeX in a script that greps the log file and accepts your
> > desired command line arguments. Then only *one* person, namely you,
> > has to do the work, and you can make the script available to any
> > other front-end authors and maintain it for them. It wouldn't take
> > long.
>
> A "script" in what language ?  Each and every front end almost certainly
> has its own scripting language, so there is no "one size fits all"
> solution when it comes to TeX front ends.  But the *TeX engine is common
> to all front ends, so it is at this point of commonality that it makes
> most sense to make the change.
>

Nowadays all TeX distros have lua.

>
> > In terms of programmer efficiency, that's much better than asking
> > several different people to hack on C (or whatever language *TeX is
> > written in) and maintain consistent lists of possible command-line
> > switch values every time you think of a new case you want to detect.
> > As observed by several of us, computer time efficiency is irrelevant
> > for such trivial tasks as grepping *TeX log files. (Even on a
> > decade-old computer, the time to grep a typical log file will be
> > measured in a very small number of milliseconds.)
>
> No "grepping" would be needed if *TeX could be asked to optionally
> return a non-zero status if a TeX warning had been issued during the
> compilation.  TeXworks already searches the log file for errors,
> warnings and bad boxes, but only if a non-zero status is returned by the
> engine; all I am asking for is for the engine maintainers to help
> TeXworks by optionally returning a non-zero status code if a warning had
> been issued.
>

I can imagine the following problems:
Overful \hbox
Overful \vbox
Underful \hbox
Uverful \vbox
Undefined label
Duplicate label
Labels have changed
Undefined citation
Duplicate citation
Missing character in a font

Now suppose that the document contains 5 overful hboxes, 12 underful
hboxes, 4 underful vboxes, 3 undefined labels, 1 duplicate labes, changed
labels, 153 missing citation, 52 missing characters. What status should be
returned so that I could get this information without looking into the log
file? (Yes/No answer might be sufficient without giving the exact numbers.)

>
> Philip Taylor
>



Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz



>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

[XeTeX] xetex installation

[Purnendu Chakraborty]

I have a naive question to the group. How do I set up xetex distribution in the
user area?  I could not find any documentation in this regard.

The reason is the following. I have TeXlive 2013 from  Opensuse 13.2. I find
that the xetex bundled with distribution is buggy. I have some issue
with Bengali
conjuncts with this version of xetex.  So I want a fresh install of
xetex without
touching the system-wide TexLive installation.

Thanks,
Purnendu


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Julian Bradfield wrote:

> Do you have a full list of all possible now-and-future events that 
> you might want to flag this way?

Yes. Anything/everything for which TeX issues a warning, either to the
log file or to the console or both. The TeX source code is so modular
and so well structured that it should be relatively easy to identify
what warnings can be issued.

> What about LaTeX/Plain TeX/AMSTeX warnings? They can be equally
> important, but I don't think the core *TeX engine knows about them.

Then there would need to be a further extension that would allow any
package to signal a warning which could be handled in the same way.

> Just wrap *TeX in a script that greps the log file and accepts your 
> desired command line arguments. Then only *one* person, namely you, 
> has to do the work, and you can make the script available to any
> other front-end authors and maintain it for them. It wouldn't take
> long.

A "script" in what language ?  Each and every front end almost certainly
has its own scripting language, so there is no "one size fits all"
solution when it comes to TeX front ends.  But the *TeX engine is common
to all front ends, so it is at this point of commonality that it makes
most sense to make the change.

> In terms of programmer efficiency, that's much better than asking
> several different people to hack on C (or whatever language *TeX is
> written in) and maintain consistent lists of possible command-line
> switch values every time you think of a new case you want to detect. 
> As observed by several of us, computer time efficiency is irrelevant 
> for such trivial tasks as grepping *TeX log files. (Even on a 
> decade-old computer, the time to grep a typical log file will be 
> measured in a very small number of milliseconds.)

No "grepping" would be needed if *TeX could be asked to optionally
return a non-zero status if a TeX warning had been issued during the
compilation.  TeXworks already searches the log file for errors,
warnings and bad boxes, but only if a non-zero status is returned by the
engine; all I am asking for is for the engine maintainers to help
TeXworks by optionally returning a non-zero status code if a warning had
been issued.

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Zdenek Wagner]

I hav tried the log from a book having 512 pages. It still contains a lot
of underful boxes. The log is not short because the book has 70 chapters,
each in a separate file, and altogether about 80 pictures. The log contains
the names af all files with chapters, all LaTeX packages, each chapter
sends its title via \typeout (which is expanded to \message), and, of
course, the names of image files are listed with additional information
(image dimensions, image types). In order to find how many underful boxes
are there, I used:

grep Underful mybook.log | wc --lines

It outputs a single number. Time needed for such a query was 0.001s. You
can do the same for overful boxes, by modifying the query you can
distinguish overful/underful vboxes and hboxes. Thus within a tiny fraction
of a second you can obtain much more precise information than from the
status code. A simple AWK script will do it in a single run, no need to
repeat grep with several arguments and piping to wc.

It is really much more useful to extraxt such pieces of information and
present them in a tabular form because you have them easily available, it
is not necessary to read the whole log file. If you only get the nonzero
status code, you know that you have a problem somewhere and you cannot find
it without reading the log or without inspecting the output. This is the
very reason why I use such scripts.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 16:30 GMT+01:00 Philip Taylor :

>
>
> Julian Bradfield wrote:
>
> > You are living 30 years ago. Today (or even 10 years ago), grepping a
> > log file for specified text consumes an unnoticeable amount of time
> > for any log file generated by a non-pathological TeX run, and it
> > allows TeXworks' problems to be solved by TeXworks, as they should be.
>
> I respectfully disagree.  I am advocating the philosophically correct
> approach, requiring a small amount of work by a small number of people
> -- those responsible for eTeX, PdfTeX and XeTeX :  I assume that LuaTeX
> can already handle this, as opposed to an inelegant and inefficient
> work-around which may require a considerable amount of work by an
> unknown but potentially somewhat larger set of people -- those
> responsible for the various now-and-future front-ends to *TeX.
>
> Philip Taylor
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Julian Bradfield]

On 2016-03-13, Philip Taylor  wrote:
> I respectfully disagree.  I am advocating the philosophically correct
> approach, requiring a small amount of work by a small number of people
> -- those responsible for eTeX, PdfTeX and XeTeX :  I assume that LuaTeX
> can already handle this, as opposed to an inelegant and inefficient
> work-around which may require a considerable amount of work by an
> unknown but potentially somewhat larger set of people -- those
> responsible for the various now-and-future front-ends to *TeX.

Do you have a full list of all possible now-and-future events that
you might want to flag this way? If not, you're requiring indefinite
attention from the various *TeX maintainers. What about LaTeX/Plain TeX/AMSTeX
warnings? They can be equally important, but I don't think the core
*TeX engine knows about them.

Just wrap *TeX in a script that greps the log file and accepts your
desired command line arguments. Then only *one* person, namely you,
has to do the work, and you can make the script available to any other
front-end authors and maintain it for them. It wouldn't take long.

In terms of programmer efficiency, that's much better than asking several
different people to hack on C (or whatever language *TeX is written
in) and maintain consistent lists of possible command-line switch
values every time you think of a new case you want to detect.
As observed by several of us, computer time efficiency is irrelevant
for such trivial tasks as grepping *TeX log files. (Even on a
decade-old computer, the time to grep a typical log file will be
measured in a very small number of milliseconds.)




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Julian Bradfield wrote:

> You are living 30 years ago. Today (or even 10 years ago), grepping a
> log file for specified text consumes an unnoticeable amount of time
> for any log file generated by a non-pathological TeX run, and it
> allows TeXworks' problems to be solved by TeXworks, as they should be.

I respectfully disagree.  I am advocating the philosophically correct
approach, requiring a small amount of work by a small number of people
-- those responsible for eTeX, PdfTeX and XeTeX :  I assume that LuaTeX
can already handle this, as opposed to an inelegant and inefficient
work-around which may require a considerable amount of work by an
unknown but potentially somewhat larger set of people -- those
responsible for the various now-and-future front-ends to *TeX.

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Philip Taylor wrote:

> Yes, it is the "inspecting the log file" that I am trying to avoid, in
> the interests of efficiency; an inspection of the log file should be
> required (as it currently is) only if the status code returned by *TeX
> is non-zero.

Or to put it even more simply :  inspection of the log file should be
required only if one reasonably suspects that something went amiss
during the compilation; the only efficient way of determining that
something went amiss during the compilation is for *TeX to return a
no-zero status code in such circumstances.  Since "something went amiss"
may well vary from user to user and from project to project, the user
should be able to specify at compile time "Warn me, via the status code,
if any of the following occurred : ...".

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Julian Bradfield]

On 2016-03-13, Philip Taylor  wrote:
> Yes, it is the "inspecting the log file" that I am trying to avoid, in
> the interests of efficiency; an inspection of the log file should be
> required (as it currently is) only if the status code returned by *TeX
> is non-zero.

You are living 30 years ago. Today (or even 10 years ago), grepping a
log file for specified text consumes an unnoticeable amount of time
for any log file generated by a non-pathological TeX run, and it
allows TeXworks' problems to be solved by TeXworks, as they should be.




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Wilfred van Rooijen wrote:

> It seems that the source code from TeXworks is available, so it should
> be possible to add a feature to "turn overfull boxes into some sort of
> error but not quite". You'd have to talk to the TeXworks people.

Only by inspecting the log file; please see below.

> On a linux computer, you could implement your own request by making an
> alias: make an executable file called "xelatex" and add it to the search
> path before the latex path; then, this new "xelatex" is really a script
> (shell script, or python, can be anything) which calls xelatex (with the
> absolute path to avoid confusion). When the xelatex run finishes, the
> script inspects the log file and provides a non-zero exit status on
> certain errors and warnings.

Yes, it is the "inspecting the log file" that I am trying to avoid, in
the interests of efficiency; an inspection of the log file should be
required (as it currently is) only if the status code returned by *TeX
is non-zero.




--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Wilfred van Rooijen wrote:

> Anyway, isn't there some kind of setting in TeXworks for this?

Not at the moment.

> Or is there perhaps a command line option for latex "turn warnings
> into errors", like with gcc?

Also not at the moment, but that is essentially what I am requesting,
except that I don't want warnings to be treated as /full/ errors
(thereby pausing the compilation and demanding user input) but rather to
simply return a non-zero status (if that what the user wants) that can
then be interpreted by an intelligent wrapper such as TeXworks.  My
suggestion is :

*TeX --return-non-zero-status-on=

(where *TeX implies any of eTeX, PdfTeX, XeTeX, etc., and 
might include "overfull-boxes", "missing-glyphs", etc.)

** Phil.





--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Dear Wilfred --

> I haven't followed the discussion in detail, but IMHO it would be
> nonsense to turn overfull boxes into errors, because they are not
> errors, rather the line breaking algorithm could not find a proper way
> to fix things differently.

I am happy to accept that, for some, overfull boxes are not errors; but
they are warnings, and I am asking only that certain categories of
warnings ( selected by the user at compile-time, and in addition to
errors,) should be able to trigger a non-zero status code.

> Remember, there is always the "draft" mode which will clearly show all
> overfull boxes marked with black lines in the final PDF.

"Draft mode" is a LaTeX concept; TeX, by default, shews the black lines,
but when one is working with 300, 400, 500pp+ documents, as I usually
am, searching visually for such things is not really an option.  If
TeXworks could be persuaded not to conceal the console log when such
warnings have been generated, a great deal of user time (and, probably,
the inadvertent release of faulty PDFs) could be saved.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Wilfred van Rooijen]

I haven't followed the discussion in detail, but IMHO it would be nonsense to 
turn overfull boxes into errors, because they are not errors, rather the line 
breaking algorithm could not find a proper way to fix things differently.
Remember, there is always the "draft" mode which will clearly show all overfull 
boxes marked with black lines in the final PDF.
Wilfred 

On Sunday, March 13, 2016 7:54 PM, Philip Taylor  
wrote:
 
 

 

Zdenek Wagner wrote:

> This is not even mentioned on the console, the user must read the log
> file. Overfull boxes make the output at least readable, missing
> characters present a serious problem.

No, they can both render the output meaningless, particularly when the
overfull box horizontally abuts another box.  This is not to say that I
by any means disagree that missing glyphs should (be capable of)
generating a non-zero status code; they most certainly should, as should
all warnings that TeX is capable of emitting.  And they could usefully
be (capable of) appearing in the console output as well as in the log
file (perhaps a second new command-line parameter, or a side-effect of
the first).

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


 
  

--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Zdeněk Wagner wrote:

> Is such a tiny time so important?

No, but the correct approach is (IMHO, of course).  We can either extend
*TeX (for a very small set of *TeX) to conditionally return a non-zero
status IFF some pre-determined set of constraints obtain, or we can
require each designer/implementor/maintainer of a front end to *TeX to
design a log parser to try to ascertain whether or not these constraints
obtain.  Is the first approach not preferable on both theoretical and
practical grounds ?

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX

[Zdenek Wagner]

It depends how efficiently the script is designed. I have a perl script
that calculates the MD5 sum of the aux file before running (Xe)LaTex (if it
does not exist, it is first created) and  after and then compares the
result. If the difer, it means that (Xe)LaTeX must be run again. If the
document uses \include, all aux files are traversed. Error status is
checked so that a document is not recompiled it there is a fatal error. The
script itself requires a fraction of a second. MD5 requires certainly more
that just looking for existence of overful boxes. If you run such a script
thousand times a day, you probably lose one or two seconds. Is such a tiny
time so important?

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 13:02 GMT+01:00 Philip Taylor :

>
>
> Jonathan Kew wrote:
>
> > I assume TeXworks will run an AfterTypeset script whether the tool it's
> > run exits with zero or non-zero code (won't it?).
>
> As far as I can tell, from the combination of Stefan's reply and my own
> observations of the behaviour of TeXworks, TeXworks runs such a script
> (to determine the contents of the "Errors, warnings, badboxes" tab), IFF
> the status returned by (Xe)TeX is non-zero.  If this is the case, then I
> would suggest that this design decision was taken in the interests of
> efficiency.  And whilst it would be grossly inefficient to run such a
> script on an $n$-thousand line log file each and every time the source
> code were compiled, the impact on the efficiency of (Xe)TeX if the
> latter were to record all warnings (etc) until the end and then
> determine on the basis of a user-set command-line parameter whether or
> not to return a zero or non-zero status would be absolutely minimal.
>
> Therefore I respectfully suggest that the correct place to make such a
> change would be in the source code of the various extended TeX engines
> (PdfTeX, XeTeX, whatever) rather than in each and every TeX front end.
>
> ** Phil.
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] [texworks] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Jonathan Kew wrote:

> I assume TeXworks will run an AfterTypeset script whether the tool it's
> run exits with zero or non-zero code (won't it?).

As far as I can tell, from the combination of Stefan's reply and my own
observations of the behaviour of TeXworks, TeXworks runs such a script
(to determine the contents of the "Errors, warnings, badboxes" tab), IFF
the status returned by (Xe)TeX is non-zero.  If this is the case, then I
would suggest that this design decision was taken in the interests of
efficiency.  And whilst it would be grossly inefficient to run such a
script on an $n$-thousand line log file each and every time the source
code were compiled, the impact on the efficiency of (Xe)TeX if the
latter were to record all warnings (etc) until the end and then
determine on the basis of a user-set command-line parameter whether or
not to return a zero or non-zero status would be absolutely minimal.

Therefore I respectfully suggest that the correct place to make such a
change would be in the source code of the various extended TeX engines
(PdfTeX, XeTeX, whatever) rather than in each and every TeX front end.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Zdenek Wagner wrote:

> This is not even mentioned on the console, the user must read the log
> file. Overfull boxes make the output at least readable, missing
> characters present a serious problem.

No, they can both render the output meaningless, particularly when the
overfull box horizontally abuts another box.  This is not to say that I
by any means disagree that missing glyphs should (be capable of)
generating a non-zero status code; they most certainly should, as should
all warnings that TeX is capable of emitting.  And they could usefully
be (capable of) appearing in the console output as well as in the log
file (perhaps a second new command-line parameter, or a side-effect of
the first).

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Zdenek Wagner]

There is a more dangerous problem which returns with a zero code, namely
missing characters. Try this XeLaTeX code:

\documentclass{article}
\usepackage{fontspec,bidi}
\setmainfont[Script=Arabic]{FreeSans}
\begin{document}
\beginR مجھے
\endR
\end{document}

This is not even mentioned on the console, the user must read the log file.
Overful boxes make the output at least readable, missing characters present
a serious problem.


Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 11:27 GMT+01:00 :

> On Sun, 13 Mar 2016, Philip Taylor wrote:
> > that no error has occurred.  All I am asking is that XeTeX be given the
> > option to inform TeXworks that an error has occurred when an overfull
> > box has been generated.
>
> Why is this a XeTeX issue and not a TeXworks issue?
>
> --
> Matthew Skala
> msk...@ansuz.sooke.bc.ca People before principles.
> http://ansuz.sooke.bc.ca/
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[mskala]

On Sun, 13 Mar 2016, Philip Taylor wrote:
> that no error has occurred.  All I am asking is that XeTeX be given the
> option to inform TeXworks that an error has occurred when an overfull
> box has been generated.

Why is this a XeTeX issue and not a TeXworks issue?

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[David Carlisle]

On 13 March 2016 at 10:14, Philip Taylor  wrote:
>
>
> David Carlisle wrote:
>
>> Philip Taylor  wrote:
>
>>> Also please consider the following text from Wikipædia :
>> (Well from Wikipedia actually)
>>
>> Yes the relevant part is
>>
>>> On many systems, the higher the value, the more severe the
>>> cause of the error.
>>
>> so the status code should be 0 unless an error is reported.
>
> I think we are arguing about semantics when we should be discussing
> functionality; an overfull box /is/ an error, whether or not it results
> in a TeX compilation being interrupted to solicit user input.

No, it is up to the person writing the code to classify things as
errors or warnings
overfull boxes are the latter.  An option to make then errors would
not be unreasonable.

>
>> I don't see why that would be a problem with an editor front end like 
>> texworks
>> most of them run tex in scrollmode so they don't stop on errors as far
>> as I can see.
>>
>> I think that you are really approaching the problem from the wrong direction.
>> editors hiding the console output is a problem but the fix should be that the
>> editors don't do that. As we see on tex.sx all the time people don't even 
>> notice
>> clear errors like undefined commands as they are using front ends that just
>> force tex to get to the end and show the pdf that results.
>
> But we are not discussing general front ends; we are discussing an
> intelligent front end such as TeXworks that does /not/ conceal the log
> file unless (a) the user has configured it so to do, or (b) it believes
> that no error has occurred.  All I am asking is that XeTeX be given the
> option to inform TeXworks that an error has occurred when an overfull
> box has been generated.

It should only inform any system that an error has occurred if
something classified
as an error has actually occurred.

>
> ** Phil.



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

David Carlisle wrote:

> Philip Taylor  wrote:

>> Also please consider the following text from Wikipædia :
> (Well from Wikipedia actually)
> 
> Yes the relevant part is
> 
>> On many systems, the higher the value, the more severe the
>> cause of the error.
> 
> so the status code should be 0 unless an error is reported.

I think we are arguing about semantics when we should be discussing
functionality; an overfull box /is/ an error, whether or not it results
in a TeX compilation being interrupted to solicit user input.

> I don't see why that would be a problem with an editor front end like texworks
> most of them run tex in scrollmode so they don't stop on errors as far
> as I can see.
> 
> I think that you are really approaching the problem from the wrong direction.
> editors hiding the console output is a problem but the fix should be that the
> editors don't do that. As we see on tex.sx all the time people don't even 
> notice
> clear errors like undefined commands as they are using front ends that just
> force tex to get to the end and show the pdf that results.

But we are not discussing general front ends; we are discussing an
intelligent front end such as TeXworks that does /not/ conceal the log
file unless (a) the user has configured it so to do, or (b) it believes
that no error has occurred.  All I am asking is that XeTeX be given the
option to inform TeXworks that an error has occurred when an overfull
box has been generated.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[David Carlisle]

On 13 March 2016 at 09:43, Philip Taylor  wrote:
> Also please consider the following text from Wikipædia :
(Well from Wikipedia actually)

Yes the relevant part is

> On many systems, the higher the value, the more severe the
> cause of the error.

so the status code should be 0 unless an error is reported.

I don't see why that would be a problem with an editor front end like texworks
most of them run tex in scrollmode so they don't stop on errors as far
as I can see.

I think that you are really approaching the problem from the wrong direction.
editors hiding the console output is a problem but the fix should be that the
editors don't do that. As we see on tex.sx all the time people don't even notice
clear errors like undefined commands as they are using front ends that just
force tex to get to the end and show the pdf that results.

David



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Zdenek Wagner]

Such a change will break a lot of build tools. If overful boxes were
reported as errors, the full build will be unsuccessful. In early stages of
devewlopment I am concerned with functionality of macros or wich
communication between several pieces of software, not with the beauty.
Overful boxes will stop me.

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz

2016-03-13 10:36 GMT+01:00 Philip Taylor :

>
>
> msk...@ansuz.sooke.bc.ca wrote:
>
> > TeXworks is free to read the log file, just like everybody else has
> > to to detect things like undefined references.
>
> Agreed, but at the moment it does not, unless the status code is
> non-zero.  I believe that the suggested command-line switch (which would
> not change the default behaviour) would be beneficial not only to users
> of TeXworks (which is a utility installed by default by TeX Live) but to
> anyone/thing else who/that needs to determine automatically whether
> something unexpected has occurred during a XeTeX compilation.
>
> ** Phil.
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

Also please consider the following text from Wikipædia :

> The parent and the child can have an understanding about the meaning
> of the exit statuses. For example, it is common programming practice
> for a child process to return zero to the parent signifying success.
> Apart from this return value from the child, other information like
> how the process exited, either normally or by a signal may also be
> available to the parent process.
> 
> The specific set of codes returned is unique to the program that sets
> it. Typically it indicates success or failure. The value of the code
> returned by the function or program may indicate a specific cause of
> failure. On many systems, the higher the value, the more severe the
> cause of the error.[1] Alternatively, each bit may indicate a
> different condition, which are then ored together to give the final
> value; for example, fsck does this.
> 
> Sometimes, if the codes are designed with this purpose in mind, they
> can be used directly as a branch index upon return to the initiating
> program to avoid additional tests.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

msk...@ansuz.sooke.bc.ca wrote:

> TeXworks is free to read the log file, just like everybody else has
> to to detect things like undefined references.

Agreed, but at the moment it does not, unless the status code is
non-zero.  I believe that the suggested command-line switch (which would
not change the default behaviour) would be beneficial not only to users
of TeXworks (which is a utility installed by default by TeX Live) but to
anyone/thing else who/that needs to determine automatically whether
something unexpected has occurred during a XeTeX compilation.

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[mskala]

On Sun, 13 Mar 2016, Philip Taylor wrote:
> "Make" (etc) are not really my concern, but the behaviour of TeXworks
> is.  If TeXworks can decide whether or not to conceal the log file based
> solely on the status code returned by TeX (XeTeX, etc), then that status

TeXworks is free to read the log file, just like everybody else has
to to detect things like undefined references.

-- 
Matthew Skala
msk...@ansuz.sooke.bc.ca People before principles.
http://ansuz.sooke.bc.ca/


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

P.S.

> "Make" (etc) are not really my concern, but the behaviour of TeXworks
> is.  If TeXworks can decide whether or not to conceal the log file based
> solely on the status code returned by TeX (XeTeX, etc), then that status
> code should (again, IMVHO) be able to indicate "things were not right"
> as well as "things were so badly wrong that I had to interrupt the
> compilation in order to seek advice from the user".

I would be perfectly happy if my preferred behaviour could be invoked
IFF a (new) command-line parameter so indicated, e.g.:

XeTeX --set-non-zero-status-on=""

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

David Carlisle wrote:

>>  non-zero status codes should be reserved for various categories
>> of warning, error, severe error, fatal error, etc., should they not ?
> 
> No I think the (now, whatever the convention in vms was) normal convention
> is that programs have a clear distinction between warnings and errors.
> 
> The engine, and the user code in the document itself should be free to
> give warnings safe in the knowledge that they _won't_ stop a build with
> make etc.

"Make" (etc) are not really my concern, but the behaviour of TeXworks
is.  If TeXworks can decide whether or not to conceal the log file based
solely on the status code returned by TeX (XeTeX, etc), then that status
code should (again, IMVHO) be able to indicate "things were not right"
as well as "things were so badly wrong that I had to interrupt the
compilation in order to seek advice from the user".

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

Re: [XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

David Carlisle wrote:

> that would seem rather odd unless you actually made them errors and
> stop with a normal
> ? error prompt etc.
> 
> The status code should reflect whether an error is reported so if
> there were an option it
> should be to make overfull boxes errors, not just to affect the status code.

Thank you for your very prompt response and comment, David, but I do not
entirely follow your logic -- whether or not something is an error is
surely not the issue :  what matters is whether something is or is not
an unqualified success.  IMVHO (and based on the VMS model, modulo 1 or
0 indicating success), a status code of zero should indicate unqualified
success; non-zero status codes should be reserved for various categories
of warning, error, severe error, fatal error, etc., should they not ?

** Phil.


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

[XeTeX] Overfull boxes return status of 0 in XeTeX

[Philip Taylor]

A (very) recent discussion on the TeXworks list included the following
extract :

>>> 6) [new] A test file yields (in the log) :
>>>
>>> Overfull \hbox (0.58942pt too wide) in paragraph at lines 20--20
>>> []\bodyfont brian.smith0...@btinternet.com[]  |
>>>
>>> With "Hide console window" set to either "Automatic" or "On success",
>>> this error message disappears; could TeXworks detect the presence of
>>> overfull box messages in the log and treat them as errors ?
>> 
>> Whether the console is closed depends solely on the exit status code of
>> the process that is doing the typesetting. It has nothing to do with the
>> actual log output (or what scripts etc. do with it). If TeX exits with
>> status code 0, the typeset run is considered a success, otherwise it's a
>> failure.
> 
> OK, then I will ask Akira-san to investigate the possibility of returning 
> non-zero when overfull boxen are reported.

Would it be possible to change the behaviour of XeTeX such that it
returns a non-zero value when overfull boxen have been generated during
the compilation ?

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex