Is relying on default widths for table columns really an error?
13 views
Skip to first unread message
Andrew Scholer
Dec 3, 2025, 11:10:45 AM (12 days ago) Dec 3
to prete...@googlegroups.com
A document I am working on reports:
PTX:ERROR: a <tabular> has at least one paragraph (<p>) inside a <cell>, yet there are no <col> elements with a @width attribute. Default widths will be supplied.
Using reasonable defaults doesn't feel like an error. A "warning" feels reasonable, but "error" feels like an extreme description as it leads to the CLI thinking something disastrous has happened:
critical: There were errors during the build. See above.
critical: Failed to build without errors. Exiting...
critical: There were errors during the build. See above.
critical: Failed to build without errors. Exiting...
Should we downgrade that report?
Andrew Scholer
Computer Science Instructor / Program Chair
Chemeketa Community College
Office hour info: https://computerscience.chemeketa.edu/people/andrew-scholer/
Office hour info: https://computerscience.chemeketa.edu/people/andrew-scholer/
Rob Beezer
Dec 5, 2025, 4:45:57 PM (10 days ago) Dec 5
to prete...@googlegroups.com
There are "errors" like you really messed up something bad in your source and we
don't know what to do and we can't recover.
And "errors" (usually labeled as a "BUG") where we fell into an "otherwise"
clause we did not expect and maybe the XSL is wrong or your source is out of
control.
And then there are "errors" where an author did something bad. 99% of these
should be caught by schema validation. Some are "run time" like an #xref to a
non-existent target, which cannot be caught by the schema.
I recently did a review to reduce the number of fatal errors we have, there are
now very few. Searching for
<xsl:message terminate="yes">
reveals fewer than twenty, and some are quite obvious (like EPUB fails if you
try to process a "slideshow").
I'd like to say that if our Python xsltproc() routine finishes gracefully
(some kind of good exit code), then there is no reason for the CLI to assume
something bad happened due to any XSL code. This could be worth some more
discussion.
Short answer:
1. I don't really care if the name of this particular message changes.
2. I think this would be very complicated to express within the schema. We do
have the "validation plus" stylesheet for exactly this sort of thing. An
informational message there might be the better place for this.
3. This is a feature Alex worked on. I'd love to have his input.
Rob
> <https://computerscience.chemeketa.edu/people/andrew-scholer/>
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N9r-sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r-
> sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
don't know what to do and we can't recover.
And "errors" (usually labeled as a "BUG") where we fell into an "otherwise"
clause we did not expect and maybe the XSL is wrong or your source is out of
control.
And then there are "errors" where an author did something bad. 99% of these
should be caught by schema validation. Some are "run time" like an #xref to a
non-existent target, which cannot be caught by the schema.
I recently did a review to reduce the number of fatal errors we have, there are
now very few. Searching for
<xsl:message terminate="yes">
reveals fewer than twenty, and some are quite obvious (like EPUB fails if you
try to process a "slideshow").
I'd like to say that if our Python xsltproc() routine finishes gracefully
(some kind of good exit code), then there is no reason for the CLI to assume
something bad happened due to any XSL code. This could be worth some more
discussion.
Short answer:
1. I don't really care if the name of this particular message changes.
2. I think this would be very complicated to express within the schema. We do
have the "validation plus" stylesheet for exactly this sort of thing. An
informational message there might be the better place for this.
3. This is a feature Alex worked on. I'd love to have his input.
Rob
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N9r-sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r-
> sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Alex Jordan
Dec 5, 2025, 5:30:49 PM (10 days ago) Dec 5
to prete...@googlegroups.com
> 1. I don't really care if the name of this particular message changes.
Me neither.
HTML could do fine if no width were specified and the table had automatic sizing. But LaTeX/PDF must have this specified (unless we entertain using a fancy package like tabularx). This can be default, if not specified by the author. So a reasonable default is there.
It's a reasonable default, but in my experience it always comes out too small. And yet it has the potential to cause horizontal overflow in PDF output, so it really should always get manual attention by the author. Hence the original decision to make it a serious "error". That goes back to when these error messages were not truly classified beyond just the text of the message.
You could change the class of the error/warning. You could also remove the default and make it actually fail. I don't have a preferred recommendation.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMi5iZWV6ZXI.1764971156%40pnsh.
Rob Beezer
Dec 5, 2025, 5:49:34 PM (10 days ago) Dec 5
to prete...@googlegroups.com
Thanks very much, Alex.
I'd vote for something similar to
PTX:WARNING: you have "p" in a table with no widths, the defaults provided are
likely to produce inferior results
but with a bit more care and precision.
I much prefer a less-than-satisfactory default to failing. My hope is that
rookie authors always get something that is at least semi-useful. Failing five
minutes before class starts is not a good look.
Rob
> > <https://computerscience.chemeketa.edu/people/andrew-scholer/ <https://
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > CACm44N9r-sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>
> > <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r- <https://
> groups.google.com/d/msgid/pretext-dev/CACm44N9r->
> > sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>?
> dev%2Bunsu...@googlegroups.com>.
> pretext-dev/MTAwMDAyMi5iZWV6ZXI.1764971156%40pnsh>.
> <https://groups.google.com/d/msgid/pretext-dev/CA%2BR-
> jrcwMSzYVX%3D%3DaNN6RkyvT2-W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
I'd vote for something similar to
PTX:WARNING: you have "p" in a table with no widths, the defaults provided are
likely to produce inferior results
but with a bit more care and precision.
I much prefer a less-than-satisfactory default to failing. My hope is that
rookie authors always get something that is at least semi-useful. Failing five
minutes before class starts is not a good look.
Rob
> computerscience.chemeketa.edu/people/andrew-scholer/>>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> > CACm44N9r-sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>
> > <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r- <https://
> groups.google.com/d/msgid/pretext-dev/CACm44N9r->
> > sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pretext-dev...@googlegroups.com <mailto:pretext-
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> MTAwMDAyMi5iZWV6ZXI.1764971156%40pnsh <https://groups.google.com/d/msgid/
> pretext-dev/MTAwMDAyMi5iZWV6ZXI.1764971156%40pnsh>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CA%2BR-jrcwMSzYVX%3D%3DaNN6RkyvT2-W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> <https://groups.google.com/d/msgid/pretext-dev/CA%2BR-
> jrcwMSzYVX%3D%3DaNN6RkyvT2-W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Andrew Scholer
Dec 5, 2025, 7:05:50 PM (10 days ago) Dec 5
to prete...@googlegroups.com
Yes, thanks Alex.
From Rob's first reply...
I'd like to say that if our Python xsltproc() routine finishes gracefully
(some kind of good exit code), then there is no reason for the CLI to assume
something bad happened due to any XSL code. This could be worth some more
discussion.
Yes, something like that is what I was thinking about.
Runestone has become permissive in terms of what it does with the CLI reporting of errors. (i.e. lets you deploy despite reported errors.) So that helps with that specific 5 minutes before class issue.
But when looking at the report from CLI and or RS, it would be nice to have a clear line between "something definitely is broken in your build" and "all the output is there, it may just not be quite what you intended". To me, that is the difference between ERROR and WARNING.
But when looking at the report from CLI and or RS, it would be nice to have a clear line between "something definitely is broken in your build" and "all the output is there, it may just not be quite what you intended". To me, that is the difference between ERROR and WARNING.
For the most part it looks like that is how things break down. But a search turns up a few other ERRORS based on "we used a default". Those muddy the picture for anyone/thing trying to summarize the build results.
Would it be reasonable to assert that those instances should all either drop the default (and be a hard ERROR) or change to a WARNING?
It would mean that for any given feature the PTX author needs to decide if a default is likely good enough to produce reasonably working output. If so, provide it and do a WARNING. If not, skip the default entirely and emit an ERROR.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzMy5iZWV6ZXI.1764974972%40pnsh.
Bradley Miller
Dec 5, 2025, 7:13:03 PM (10 days ago) Dec 5
to prete...@googlegroups.com
Andrew,
A while ago, Rob added (and Runestone looks for FATAL). That allows Runestone to distinguish between ERRORS, but the book is still built hence the message - Non-Fatal errors detected, see log for details. And FATAL errors where PreTeXt just gives up and does not do a build.
Brad
Brad Miller
Professor Emeritus, Luther College
Founder, Runestone Academy LTD
Blog: http://reputablejournal.com
Set up a time to meet with me.
Professor Emeritus, Luther College
Founder, Runestone Academy LTD
Blog: http://reputablejournal.com
Set up a time to meet with me.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/CACm44N_nFhriP%3DN4ZFGpkMJ43_SY2QcSsYbxk9bUU5WYsXwMdw%40mail.gmail.com.
Rob Beezer
Dec 5, 2025, 9:25:19 PM (10 days ago) Dec 5
to prete...@googlegroups.com
As Brad mentions, we do have "FATAL". (I'd already forgotten about that!)
> Would it be reasonable to assert that those instances should all either drop
the default (and be a hard ERROR) or change to a WARNING?
Without doing a survey, I'd suggest we should not remove any (crafted) default
behavior. If that means a lot of ERROR -> WARNING, that's fine. We should be
clear about what an author has got wrong.
And as I think Alex intimated, a lot of this is from before we were very careful
about what belonged to validation and what we might emit at run time.
Is that enough guidance? Want to post some tricky cases here first for discussion?
Rob
On 12/5/25 16:05, Andrew Scholer wrote:
> Yes, thanks Alex.
>
> From Rob's first reply...
>
> I'd like to say that if our Python xsltproc() routine finishes gracefully
> (some kind of good exit code), then there is no reason for the CLI to assume
> something bad happened due to any XSL code. This could be worth some more
> discussion.
>
>
> Yes, something like that is what I was thinking about.
>
> Runestone has become permissive in terms of what it does with the CLI reporting
> of errors. (i.e. lets you deploy despite reported errors.) So that helps with
> that specific 5 minutes before class issue.
>
> But when looking at the report from CLI and or RS, it would be nice to have a
> clear line between "something definitely is broken in your build" and "all the
> output is there, it may just not be quite what you intended". To me, that is the
> difference between ERROR and WARNING.
>
> For the most part it looks like that is how things break down. But a search
> turns up a few other ERRORS based on "we used a default". Those muddy the
> picture for anyone/thing trying to summarize the build results.
>
> Would it be reasonable to assert that those instances should all either drop the
> default (and be a hard ERROR) or change to a WARNING?
>
> It would mean that for any given feature the PTX author needs to decide if a
> default is likely good enough to produce reasonably working output. If so,
> provide it and do a WARNING. If not, skip the default entirely and emit an ERROR.
>
>
>
> On Fri, Dec 5, 2025 at 2:49 PM 'Rob Beezer' via PreTeXt development <pretext-
> > d...@googlegroups.com <mailto:d...@googlegroups.com> <mailto:pretext-
> andrew- <https://computerscience.chemeketa.edu/people/andrew->
> > scholer/ <https://computerscience.chemeketa.edu/people/andrew-
> > computerscience.chemeketa.edu/people/andrew-scholer/ <http://
> <mailto:dev%252Buns...@googlegroups.com>> <mailto:pretext-
> <mailto:pretext-> <mailto:pretext- <mailto:pretext->>
> > > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>
> > <mailto:dev%2Bunsu...@googlegroups.com
> <mailto:dev%252Buns...@googlegroups.com>>>.
> > dev/ <https://groups.google.com/d/msgid/pretext-dev/ <https://
> groups.google.com/d/msgid/pretext-dev/>>
> > > CACm44N9r-
> sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>
> > <http://40mail.gmail.com <http://40mail.gmail.com>>
> > > <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r-
> <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r-> <https://
> > groups.google.com/d/msgid/pretext-dev/CACm44N9r- <http://
> groups.google.com/d/msgid/pretext-dev/CACm44N9r->>
> > > sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>
> > <http://40mail.gmail.com <http://40mail.gmail.com>>?
> > dev%2Bunsu...@googlegroups.com
> <mailto:dev%252Buns...@googlegroups.com>>.
> msgid/ <https://groups.google.com/d/msgid/>
> W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com <http://40mail.gmail.com>
> > <https://groups.google.com/d/msgid/pretext-dev/CA%2BR- <https://
> groups.google.com/d/msgid/pretext-dev/CA%2BR->
> > jrcwMSzYVX%3D%3DaNN6RkyvT2-W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com
> pretext-dev/MTAwMDAzMy5iZWV6ZXI.1764974972%40pnsh>.
> groups.google.com/d/msgid/pretext-dev/
> CACm44N_nFhriP%3DN4ZFGpkMJ43_SY2QcSsYbxk9bUU5WYsXwMdw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
> Would it be reasonable to assert that those instances should all either drop
the default (and be a hard ERROR) or change to a WARNING?
behavior. If that means a lot of ERROR -> WARNING, that's fine. We should be
clear about what an author has got wrong.
And as I think Alex intimated, a lot of this is from before we were very careful
about what belonged to validation and what we might emit at run time.
Is that enough guidance? Want to post some tricky cases here first for discussion?
Rob
On 12/5/25 16:05, Andrew Scholer wrote:
> Yes, thanks Alex.
>
> From Rob's first reply...
>
> I'd like to say that if our Python xsltproc() routine finishes gracefully
> (some kind of good exit code), then there is no reason for the CLI to assume
> something bad happened due to any XSL code. This could be worth some more
> discussion.
>
>
> Yes, something like that is what I was thinking about.
>
> Runestone has become permissive in terms of what it does with the CLI reporting
> of errors. (i.e. lets you deploy despite reported errors.) So that helps with
> that specific 5 minutes before class issue.
>
> But when looking at the report from CLI and or RS, it would be nice to have a
> clear line between "something definitely is broken in your build" and "all the
> output is there, it may just not be quite what you intended". To me, that is the
> difference between ERROR and WARNING.
>
> For the most part it looks like that is how things break down. But a search
> turns up a few other ERRORS based on "we used a default". Those muddy the
> picture for anyone/thing trying to summarize the build results.
>
> Would it be reasonable to assert that those instances should all either drop the
> default (and be a hard ERROR) or change to a WARNING?
>
> It would mean that for any given feature the PTX author needs to decide if a
> default is likely good enough to produce reasonably working output. If so,
> provide it and do a WARNING. If not, skip the default entirely and emit an ERROR.
>
>
>
> > scholer/ <https://computerscience.chemeketa.edu/people/andrew-
> scholer/ <https://computerscience.chemeketa.edu/people/andrew-scholer/>>
> > > <https://computerscience.chemeketa.edu/people/andrew-scholer/
> <https://computerscience.chemeketa.edu/people/andrew-scholer/> <https://
> > > <https://computerscience.chemeketa.edu/people/andrew-scholer/
> > computerscience.chemeketa.edu/people/andrew-scholer/ <http://
> computerscience.chemeketa.edu/people/andrew-scholer/>>>
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "PreTeXt development" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> send an
> > email
> > > to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> > dev%2Bunsu...@googlegroups.com
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "PreTeXt development" group.
> > > To unsubscribe from this group and stop receiving emails from it,
> send an
> > > to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> <mailto:dev%252Buns...@googlegroups.com>> <mailto:pretext-
> <mailto:pretext-> <mailto:pretext- <mailto:pretext->>
> > > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>
> > <mailto:dev%2Bunsu...@googlegroups.com
> <mailto:dev%252Buns...@googlegroups.com>>>.
> > > To view this discussion visit https://groups.google.com/d/msgid/
> pretext- <https://groups.google.com/d/msgid/pretext->
> > dev/ <https://groups.google.com/d/msgid/pretext-dev/ <https://
> groups.google.com/d/msgid/pretext-dev/>>
> > > CACm44N9r-
> sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>
> > <http://40mail.gmail.com <http://40mail.gmail.com>>
> > > <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r-
> <https://groups.google.com/d/msgid/pretext-dev/CACm44N9r-> <https://
> > groups.google.com/d/msgid/pretext-dev/CACm44N9r- <http://
> groups.google.com/d/msgid/pretext-dev/CACm44N9r->>
> > > sOZegx3%2BoZ87fSFX7F1xc6L8%3DjCN2yURnwrjooPRw%40mail.gmail.com
> <http://40mail.gmail.com>
> > <http://40mail.gmail.com <http://40mail.gmail.com>>?
> > > utm_medium=email&utm_source=footer>.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to pretext-dev...@googlegroups.com <mailto:pretext-
> > dev%2Bunsu...@googlegroups.com
> <mailto:dev%252Buns...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/
> pretext-dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> > MTAwMDAyMi5iZWV6ZXI.1764971156%40pnsh <https://groups.google.com/d/
> pretext-dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> msgid/ <https://groups.google.com/d/msgid/>
> > pretext-dev/MTAwMDAyMi5iZWV6ZXI.1764971156%40pnsh>.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> email
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "PreTeXt development" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com> <mailto:pretext- <mailto:pretext->
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> > CA%2BR-jrcwMSzYVX%3D%3DaNN6RkyvT2-
> > dev+uns...@googlegroups.com
> <mailto:dev%2Bunsu...@googlegroups.com>>.
> > To view this discussion visit https://groups.google.com/d/msgid/pretext-
> dev/ <https://groups.google.com/d/msgid/pretext-dev/>
> W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com <http://40mail.gmail.com>
> > <https://groups.google.com/d/msgid/pretext-dev/CA%2BR- <https://
> groups.google.com/d/msgid/pretext-dev/CA%2BR->
> > jrcwMSzYVX%3D%3DaNN6RkyvT2-W5vfwxq5tNhZtTD%2BZeSeokg%40mail.gmail.com
> <http://40mail.gmail.com>?
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> MTAwMDAzMy5iZWV6ZXI.1764974972%40pnsh <https://groups.google.com/d/msgid/
> > utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pretext-dev...@googlegroups.com <mailto:pretext-
> dev%2Bunsu...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> pretext-dev/MTAwMDAzMy5iZWV6ZXI.1764974972%40pnsh>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> CACm44N_nFhriP%3DN4ZFGpkMJ43_SY2QcSsYbxk9bUU5WYsXwMdw%40mail.gmail.com <https://
> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-dev...@googlegroups.com <mailto:pretext-
> dev+uns...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/
> groups.google.com/d/msgid/pretext-dev/
> CACm44N_nFhriP%3DN4ZFGpkMJ43_SY2QcSsYbxk9bUU5WYsXwMdw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.
Andrew Scholer
Dec 6, 2025, 2:14:13 PM (9 days ago) Dec 6
to prete...@googlegroups.com
Yes, I know about FATAL and the recent RS changes. The division between FATAL and ERROR seems to be a nice clear line in both theory and practice (FATAL terminates, ERROR at least completes the main processing).
There aren't that many spots. How about I make a PR with them. In it I'll list the changes and tag whoever last touched that item so they can offer insight or corrections.
Related note:
It would be useful to distinguish author errors from internal issues. PTX:ERROR vs PTX:BUG mostly do that. But again, the boundary on their use has been a little fuzzy historically. This is less of an issue since they both end up mapped to python log level "error". But it still might be nice to standardize.
As an example, to me this would make more sense as a PTX:BUG. If an author sees it appear, there is nothing they can do about it other than report it.
<xsl:template name="code-wrapper">
<xsl:message>PTX:ERROR: current conversion needs an implementation of the "code-wrapper" template</xsl:message>
</xsl:template>
As an example, to me this would make more sense as a PTX:BUG. If an author sees it appear, there is nothing they can do about it other than report it.
<xsl:template name="code-wrapper">
<xsl:message>PTX:ERROR: current conversion needs an implementation of the "code-wrapper" template</xsl:message>
</xsl:template>
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDA0NC5iZWV6ZXI.1764987916%40pnsh.
Reply all
Reply to author
Forward
0 new messages