Update of bug #66653 (group groff):
Status: None => Need Info
Assigned to: None => deri
Summary: .asciify odd behaviour / adding pdf features to ms
=> [patch][troff].asciify odd behaviour / adding pdf features to ms
_______________________________________________________
Follow-up Comment #8:
The attached patch fixes the first problem (truncation of the result of
asciifying) and may be a fix for the elusive crash (it certainly stops the
crashing with this reproducer). In addition I have brought the result of
asciify into line with Branden's new \X handling, i.e. any glyph which has not
got an ascii code is represented in its \[uXXXX] form.
Technical Note
In order to extract "text" back from nodes in a diversion (or box) asciify
should only be interested in glyph_nodes and word_space_nodes, since these are
the nodes created from text in the first place. Unfortunately when trying to
asciify other types of node, intead of text chars being added, a '\000' is
added instead (which results in truncation when treated as a string. This is
why the ms versions of .I caused truncation since the the italic correction
also includes a dummy_node, which is one of nodes which adds '\000', the other
I discovered was tag_node, there may well be others. The \& is another escape
which can add a dummy_node so "G.\& Branden Robinson" (as a co-author) got
truncated to just "G."
This patch prevents these two node types interfering with asciify.
One strange thing I observed in the truncated macros is that the cl structure
which contains members ptr, head, tail and len, was in a case where the
diversion started with a tag_node (devtag TL) so the string appears empty
(starts with '\000') and ptr, head and tail all point to the same address but
len held a positive number equal to the number of characters added to the
macro by asciify. This may be expected behaviour, len could be the number of
bytes of allocated memory, but I just wondered what would happen if this was
subsequently .chop(ped). So this might be the reason for the assert crash dump
at the end of the run, but I would not bank on it, it is a slippery fellow.
The patch can probably be improved, I'd appreciate Branden's insight.
My "proof of concept" work on adding pdf features to the ms macros is coming
along, the attached pdfs are examples. Both djms.pdf and djpic.pdf are run
with the current ms source documents (with just the addition of ".RP no"
adding a separate title page so the TOC can be auto relocated to page after
the title) against my current version of pdfms.tmac (still got a few wrinkles
to sort out so it is not attached - yet). When finished I am hoping Branden
wants to incorporate this work into s.tmac, probably after 1.24, with suitable
.if '\*[.T]'pdf' protections. The pdfmark2.pdf is using the latest pdfmark.ms
before it was removed from git and requires "pdfmom --roff -ms" and my new
pdfms.tmac to work. Things to notice are author and title correct if you run
pdfinfo and a clickable TOC. All of these needed the patch applied to work
properly.
(file #56781, file #56782, file #56783, file #56784)
_______________________________________________________
Additional Item Attachment:
File name: asciify.patch Size: 856B
<https://file.savannah.gnu.org/file/asciify.patch?file_id=56781>
File name: djpic.pdf Size: 103KiB
<https://file.savannah.gnu.org/file/djpic.pdf?file_id=56782>
File name: djms.pdf Size: 81KiB
<https://file.savannah.gnu.org/file/djms.pdf?file_id=56783>
File name: pdfmark2.pdf Size: 69KiB
<https://file.savannah.gnu.org/file/pdfmark2.pdf?file_id=56784>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-04e1be7c5875649835636cff39891da2b16ab95a.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66653>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
