Follow-up Comment #4, bug #68022 (group groff): At 2026-02-06T12:29:00-0500, Deri James wrote: > Follow-up Comment #3, bug #68022 (group groff): > On Friday, 6 February 2026 13:28:57 GMT G. Branden Robinson wrote: >> Your presentation makes sense to me. I think of these as a set of >> "optimizations" (maybe that's what you were going for with `--opt`, >> rather than the "options" I inferred). > > The problem is they are not all "optimisations", certainly not bit 3, > it will produce a less than optimal pdf. In terms of size of pdf > produced I can see your thought process.
Right. Commonly in CS/SW-engineering we speak of optimizations in space (memory/storage consumption) vs. optimizations in time (CPU cycles). Those two don't exhaust the applications of optimization, but they do threaten to overwhelm people into thinking they do. "Optimizing to minimize cache pressure", for example, can result in code that runs faster _and_ is smaller. (And the original Mach microkernel's inattention to this precise factor has been used as a club to deride the performance of all microkernels ever since.[1][2] Including by Macintosh users who have been running a Mach-based system for 25 years, boasting of its performance the entire time.) > Perhaps it will help if I tell you why each facility is there. > > Bit 0: The font subsetting code is new and complex, I'd be a fool to > imagine it will work perfectly with every font in existence. So if a > problem is discovered with a particular font, I can ask to re-run with > this bit off to test if the problem is related to the new code, if it > works then at least the user has a workable solution, which takes the > pressure off me to find the actual problem with the code. Sounds reasonable. > Bit 1: Switching to using the "non-space" algorithm is in fact > automatic on a font by font basis. Gropdf used to output a message > each time it switched but I believe you committed a change to only > output the message if gropdf was in debug mode, which I agreed with. > Our EURO font has no space glyph so the message was appearing whenever > the EURO font was active. This bit was included so that I could force > the non-space algorithm on fonts with a space glyph to ensure both > algorithms produced visually identical results. Sounds reasonable. > Bit 2: Optionally every dictionary object in a pdf can be immediately > followed by a stream (stream...endstream), think of it as the payload > and the dictionary is the attributes associated with it. Streams are > normally flate compressed which makes them unreadable with less or an > editor, this bit stops the flate compression. Ahhh. > Bit 3: Even with flate turned off streams which hold font data are > binary and encoded, so can't be "read" and are often a significant > portion of the total size of the pdf. When debugging a pdf issue, it > helps to drop this binary font data to make traversal with an editor > easier. Is there no alternative, plain-text representation format for these streams specified? Not Base64 or something like that? If not, then I have yet another answer to the old standby question "know how we can tell coders from Adobe and Microsoft came up with this?". > As you can see these flags are technical tweaks to the pdf, not > optimisations. Maybe they're optimizations for maintainability. :) > I still think --opt (-O) is better given they are not really > optimisations. But "opt", while meaningful as a verb, _looks_ like an abbreviation of "option(s)"..._or_ "optimization(s)"! If we're going to have a long option name at all, it should me a meaningful word or phrase. Long option names are supposed to, according to the GNU Coding Standards, be "mnemonic". See, e.g., https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html and https://www.gnu.org/prep/standards/html_node/Option-Table.html . (`--pdfver` also sits somewhat uneasily with the foregoing guidance.) Maybe -f, --format-options ? Happy to draft a new cut of my man page revisions if we can settle on the command-line interface. > (file #58221) Unfortunately this attachment didn't come off. $ file ~/Downloads/NoSpaceFont.png /home/branden/Downloads/NoSpaceFont.png: data [1] https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate#The_debate [2] https://www.cs.fsu.edu/~awang/courses/cop5611_s2026/microkernel.pdf _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?68022> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
