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 eit
On 13 March 2016 at 08:53, Philip Taylor wrote:
> 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...@btinter
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 th
> 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,
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 w
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 righ
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 f
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 ch
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 val
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
Zdenek Wagner wrote:
> Such a change will break a lot of build tools.
With respect, Zdeněk, the proposed change (a new command line parameter)
will not break any build tools; it will add functionality,. not modify it.
** Phil.
--
Subscriptions,
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
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 un
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
>
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.
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
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
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 de
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
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/impl
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
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, overfu
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
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.
> O
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.
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 : inspectio
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 s
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
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
send
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 th
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 Beng
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. Th
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
b
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".
> Now
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 d
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 faci
2016-03-13 18:26 GMT+01:00 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
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 ?
-
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
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 t
>
> 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 b
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, com
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
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
use
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 i
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://tt
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)
fullnamelan
47 matches
Mail list logo