Follow-up Comment #1, bug #68781 (group groff): At 2026-10-15T17:17:14-0400, Deri James wrote: > In grops 'ps: import' stands the image on the text baseline, whereas > 'pdf: pdfpic' hangs it on the baseline. Both PDFPIC and PSPIC hang the > image, so there was no way of replicating what 'ps: import' provides. > > This has caused confusion in the past (see > https://lists.gnu.org/archive/html/groff/2022-11/msg00088.html). This > will simplify inlining images.
I like this idea. Earlier this year I was confronted with the 'ps: import' device extension command and found it vexing that it didn't delimit its argument or otherwise accept a special syntax for encoding the file name, but instead parsed its arguments into "words". That led to a problem, long-standing but now fixed. commit 3286e0681805eca77ac7518c8cdff0beb54eabb6 Author: G. Branden Robinson <[email protected]> Date: Fri Jul 24 15:51:10 2026 -0500 [grops]: Fix Savannah #68560. * src/devices/grops/ps.cpp (ps_printer::do_import): Revise to avoid overreading heap by one byte with certain ill-formed arguments to the `import` device extension command. Recast error diagnostic to report the full contents of the invalid argument and characterize it simply as "invalid" due to non-numeric contents. Also clarify the language of these diagnostics. The grammar of "trout"/"grout" is such that the device control command reads, to the end of the line, one big "argument" containing space-delimited parameters. Fixes <https://savannah.gnu.org/bugs/?68560>. Thanks to Bruno Haible for the concurrent discovery. Problem introduced by me in commit 9f050b7ed7, 7 May. With this commit, for me on my system (GNU/Linux amd64 using GCC 10.2.1), groff now builds and runs its test suite successfully with the following compiler options. -fsanitize=address -fsanitize-undefined-trap-on-error -fsanitize=signed-integer-overflow -fsanitize=undefined However we can't employ the full power of ASAN yet. I'm using `ASAN_OPTIONS="detect_leaks=0 abort_on_error=1 allocator_may_return_null=1 alloc_dealloc_mismatch=0"`. I'm informed that Clang's ASAN is more sensitive. However I'm unable to use Clang 11.0.1 to build groff in this same environment because it doesn't get along well with Gnulib's <stdckdint.h> implementation and our attempt to hew to ISO C++98; it blows up complaining that the `long long` data type demands C++11. (Happily, [https://lists.gnu.org/archive/html/groff/2026-10/msg00020.html Bruno Haible reported good news regarding Clang's ASAN and UBSAN with respect to a _groff_ 1.25.0.rc3 build].) I'd therefore like to propose different syntax for "pdf: inline" in its initial implementation so that we don't have to change it later. The synopsis of "ps: import" is as follows. _grops_(1): \X'ps: import file llx lly urx ury width [height]' I propose the following tweak for "pdf: inline". \X'ps: inline encoded-file-name llx lly urx ury width [height]' ...where _encoded-file-name_ is the file name of concern with all code points in the range U+0021 (!) to U+007E (~), except for U+005C (\), encoded as themselves. Any other code points in the file name are to be encoded in `\[u00nn]` syntax where nn is the code point in hexadecimal. If this method looks familiar, that is because it is the same one we're using for encoding of non-ASCII code points in PDF metadata and bookmarks, and because it is a subset of the more general Unicode special character escape sequence of GNU _troff_ itself. groff_char(7): \[unnnn[n[n]]] is a Unicode numeric special character escape sequence. Any Unicode code point can be accessed with four to six hexadecimal digits, with hexadecimal letters accepted in uppercase form only. Thus, \[u02DA] accesses the (spacing) ring accent, producing “˚”. For example, inlining a file named "my cat.jpg", a "full HD" image, would be done as follows. \X'pdf: inline my\[u0020]cat.jpg 0 1080 1920 0 1920' For now I recommend encoding only single bytes in this manner because we don't have a mechanism for informing _grops_ or _gropdf_ that it needs to transform an integral Unicode code point (any value in the range 0..10FFFF) to UTF-8, UTF-16LE, UTF-16BE, or whatnot. For file name references like these, the encoding might depend not on the POSIX locale per se but on the convention of the file system, which is not de jure standardized by POSIX and, as far as I know, lacks any POSIX standard interface for obtaining such information. On the bright side, this limitation shouldn't cause any grief for users because both the producer and consumer ends of this syntax are managed by _groff_ developers. If someone maintains a third-party output driver for _groff_, they can of course make themselves known and work with us. What do you think? _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68781> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
