Need more detailed error

[Mark Fitch]

Below is an error message from pretext-cli. Unfortunately it does not contain any information that I can use to find where this error occurred. It is in code generated by the MOM process, so it is in one of a long list of separate files. Is there any way to track this down (various verbose settings made no difference).

Note I know the cause of the error: MOM problem uses html table and includes a table in that table. I thought I had removed all of these but apparently I missed one.

comprehensive messages, warnings, and errors:
    * PTX:ERROR:   cell with p element has no corresponding col element with width attribute
processing with C:\Users\mafitch\.ptx\xsl\pretext-latex.xsl has failed

critical: PTX:ERROR:   cell with p element has no corresponding col element with width attribute
##################
Failed to build pdf.  Exiting...
While running pretext, the following errors occured:

critical: PTX:ERROR:   cell with p element has no corresponding col element with width attribute

Dr. Mark A. Fitch
Professor of Mathematics
Chair, Associate of Arts

maf...@alaska.edu

SSB 154
University of Alaska Anchorage
3211 Providence Drive, Anchorage, AK 99508

[Rob Beezer]

That is an XSL/PreTeXt error, so no fault of the CLI.

I once went on a quest to root out all fatal errors - my philosophy is to at
least fall back to some default or something and do our best to finish
processing. That might let you locate a mangled table in the PDF.

A "location report" at that juncture would be a good idea. (A standard template
that tries to tell you via titles or @xml:id where to go look.)

But that doesn't help you right now, even if I added it.

HTML should not fail. Would a table in a table be apparent there?

Can you grep your generated/mom directory for "<table" and maybe locate
suspicious files/situations.

You could do a binary divide-and-conquer by "commenting" out parts of your source?

I could also tell you where/how to add a template that gives more info, but I'd
be guessing about where the CLI has the right stylesheet to edit.

Rob

> --
> You received this message because you are subscribed to the Google Groups
> "PreTeXt support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to pretext-suppo...@googlegroups.com
> <mailto:pretext-suppo...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pretext-support/f53a4d0e-0c2d-547f-d39d-546a04a0bbc5%40alaska.edu <https://groups.google.com/d/msgid/pretext-support/f53a4d0e-0c2d-547f-d39d-546a04a0bbc5%40alaska.edu?utm_medium=email&utm_source=footer>.

[Mark Fitch]

grep has been my friend for finding the rest of the errors. The
processing got far enough a minute ago that it actually ran xelatex. I
think I have one more problem to find. I also need to download a lot of
graphics and update the <image> tags to use them.

There are about three categories of MOM issues now. Most seem easy to
avoid. Some can probably be fixed. I need to contact MOM again and
report the ones that could perhaps be easily fixed. I should also get on
pretext-dev to discuss one last bit of code that may be needed. More
reports after my next steps.

[Rob Beezer]

Thanks for the update.

On 11/22/22 10:47, Mark Fitch wrote:
> There are about three categories of MOM issues now. Most seem easy to avoid.
> Some can probably be fixed. I need to contact MOM again and report the ones that
> could perhaps be easily fixed. I should also get on pretext-dev to discuss one
> last bit of code that may be needed. More reports after my next steps.

Thanks! It'd be great to have MOM make changes they can, and if we could
provide (even limited) advice about how to work through the process you have
pioneered.

Rob

[Alex Jordan]

I could help with making this a nonfatal error.

For background, if a table cell has a "p" in it, then what's going to
happen in LaTeX? There will be a LaTeX tabular environment, and
somewhere in it there is a cell that has long content. LaTeX is not
going to line wrap that content. You will just get a table that
overflows. So the column there needs to be marked as a fixed with "p"
column in the tabular alignment array argument. But that requires
saying how wide that fixed width should be. PTX wants the PTX source
to have a col element that declares that width. Currently it is
failing without that.

I could make it default to, say, 20% and give a warning. If that is
too narrow you will see a tall table in the PDF output.

Or I could make it default to 100% and then the table will definitely
overflow because of other columns having width too.

Tell me what is best and I can make the change, together with a
runtime warning that a default is being used where something explicit
should be declared.

Note that the schema can't easily capture this for an early warning.
That's because there is a cell with a p, and it's the p's parent's
(cell) parent's (row) parent's (tabular) child's (col) attribute
(width) that needs to be present.

> --
> You received this message because you are subscribed to the Google Groups "PreTeXt support" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to pretext-suppo...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/af4ad7aa-b651-3a46-0c4f-95d1bc38e841%40ups.edu.

[Rob Beezer]

Thanks, Alex. Whatever you think is best would be great. I'd lean to the 20%
solution. Maybe a crappy presentation, but not ridiculously so.

Definitely, a use of the "location-report" template as part of the warning would
help with problems like Mark F has right now.

Perhaps the schema can have tables-with-cols and tables-without-cols. The
former requires the "cols" (and the widths?), the latter does not. Maybe even
that is not sufficient. And in any event, not really desirable, so not worth
pursuing, I think.

Does the "validation-plus" stylesheet provide a home for this check? Situations
like this are exactly the raison d'etre for that stylesheet.

Rob

[Alex Jordan]

Sort of funny. The place where this happens already has:
<xsl:apply-templates select="." mode="location-report" />

So it should be giving a location report.

Except that line comes *after* an xsl:message with terminate="yes"...

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/671b4fe4-c458-d545-d32b-e963ec3f8f3f%40ups.edu.

[Rob Beezer]

Not funny! ;-)

That possibility already ran through my head...

Are we going to hit it with "git blame"? ;-)

Rob

[Alex Jordan]

> Are we going to hit it with "git blame"? ;-)

Oh I have no doubt this comes from me.

How high end do you want the fix to be?

Kia: change a few lines of code in the latex and html stylesheets to
default to 20% with location reporting.

Cadillac: Do "repair" in assembly to add "col" elements when needed,
and add "width" attributes when needed. Again with location reporting
that this should actually be fixed in the author source. This could be
a little nontrivial because when doing an assembly phase, we'd need to
pause when we enter a "tabular" and look ahead down below to see if
there are any paragraph columns, and identify which columns they are,
accounting for colspan. And then if there are already col elements,
determine which ones need the @width added.

[Alex Jordan]

Or Lada: leave it all alone except move the terminate to *after* the
location reporting.

[Rob Beezer]

Kia. Just enough to allow processing to continue, i.e. the error message
becomes non-fatal.

I think of "repair" as being problems *we* have caused due to being immature and
having a rolling release schedule. We *want* authors to know their source is
not up to snuff and that they should fix it. Thus (annoying) messages until
they do. (Maybe there are already exceptions?)

Rob

[Alex Jordan]

PR opened at:
https://github.com/PreTeXtBook/pretext/pull/1863

I debated with myself whether 20% should just be a default. So,
omitting the column width would not be an error. But that situation
leaves it possible for total width to exceed 100%, so at least at some
level it is an error for authors not to intentionally set a value.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/c6e684df-52e9-c68d-8581-579a9bd88f50%40ups.edu.

[Rob Beezer]

Thanks, Alex! Merged, and updating website right now. I think 6 columns at 20%
might be even more confusing for an author. So I like it as-is.

Mark - you could grab the CLI nightly if you wanted to get the better error
report (and it will not be fatal anymore).

Rob

[Rob Beezer]

More on this for Alex. A week ago we (Alex and I) made this error non-fatal:

https://github.com/PreTeXtBook/pretext/pull/1863

But now WW problems coming back from the server are triggering the new error
message. :-(

Build sample chapter representations, see number 59, 74, and 77. Build HTML and
they all complain.

1. Long-term: without looking too carefully, the majority (all?) of these cells
do not need to be in a "p"? So maybe server-processing (or PGML construction?)
needs adjustment. Perhaps authored source? I've not dug too deep.

2. Short-term. These error messages should be notices to authors. And we
should be manufacturing 100% legal PreTeXt out of the pre-processor. (Duh!) So
maybe we should have messages in the early (original) source analysis/warnings
phase. We could at least easily see at least one "cell/p" and no "col/@width"
at all. That does not line up the columns, but would catch naive uses in error
and could warn about defaults being applied. We could still *silently* apply a
20% default at each exact offending instance during processing.

3. Unclear to me why we were not alerted to this months ago. But not too
important, I guess.

Thoughts?

Rob

[Alex Jordan]

As it happens, I've been working on a complete rebuild of PG's
table-making macros. This was triggered by the project Matt and
Chrissy are doing. The new table making macro will preserve most PTX
structure. In particular, cells that are supposed to have p's in them
can have columns that declare their widths. It will take me a bit
longer to complete that project. I can put the new macro file on the
AIM and Runestone servers, but it won't be distributed generally until
late spring/early summer with WW 2.18.

Now there will still be p's inside cells that shouldn't have been p's
in the first place. I do not understand why processing was not
terminating even prior to the recent change. That was fatal before our
recent change...

I will think about how best to scrub away those p's without also
scrubbing away the ones that should stay. If nothing else, some XML
surgery using lxml during the representations build would get the job
done.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-support/e9e77d9f-f083-93ae-41e9-f6280314e3d1%40ups.edu.

[Rob Beezer]

I've moved the error message out of the HTML and LaTeX processing
(post-WW-server) and replaced it with a cruder check in the pre-pre-processing
of an author's source that is employed for *every* conversion. There will still
be a 20% default supplied everywhere it is necessary.

As much as possible, deficiencies in author's source should be located, in order,

1. by the schema

2. by the validation-plus stylesheet

3. before the pre-processor engages

4. in the midst of processing

I think this belongs in (2), though it will be a chore to get the correspondence
between the "col" and the "cell" in each row. But maybe just a recursive
template to track both and stay in-sync.

Rob