misrendered PDF (unreadable trailing "d")

[dkg]

Describe the issue

Section 4.1.2.2 of the PDF form of draft-ietf-lamps-e2e-mail-guidance-06 makes it look like there is a missing "d".

The text in that section says:

└┬╴multipart/encrypted
 ├─╴application/pgp-encrypted
 └─╴application/octet-stream

But it renders without the trailing "d" on application/pgp-encrypted.

I can't replicate this misrendering with my own toolchain (this pdf was generated by the datatracker directly), so i don't know what specifically is causing the problem.

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[kesara]

This seems like a datatracker's HTMLized PDF generation issue since xml2rfc generates all formats correctly.

[larseggert]

CC @martinthomson

[larseggert]

There is also an issue with the asterisks in the list following the figure.

The short answer here is that weasyprint's CSS support is real bad. We need to find a hack that makes it work.

[cabo]

Here are reviewer comments on https://datatracker.ietf.org/doc/pdf/draft-ietf-jsonpath-base-13

The bullets on the bottom of page 24 (why are there no page numbers?)
and top of page 25 have no spaces after them:

 - equal objects with no duplicate names…

   oboth objects …
   ofor each of those names, …

And on closer inspection that seems to be the case for fifth or sixth
level bullets generally.

The other thing is that the heading “Parameters:” for each of the
extension functions is mangled such that it reads “ParameteXs” where X
is an overstrike of “r” and “1”. It looks like the parameters are a
numbered list and the spacing is off. By the time you get down to 2.4.7,
you can see that the second item in the list begins “2.” at the same
horizontal location as the “1” that mangles the “r” in parameters.

Honestly, I have no idea why we are torturing people with this form of pdfization if it is so easy to do the real thing.

[larseggert]

You mean PDFize the HTML? Happy to switch to that, but users will need to be OK with that (past feedback wanted the text version PDFs.)

[cabo]

You mean PDFize the HTML? Happy to switch to that, but users will need to be OK with that (past feedback wanted the text version PDFs.)

I'm not sure I understand the terminology, but I don't understand why we have to have a different (and vastly inferior) rendering from the (mostly) debugged one that is provided by xml2rfc.

[cabo]

(past feedback wanted the text version PDFs.)

(Trying to interpret the terminology:
Note that the .txt files have page numbers; the datatracker PDFs don't.
What are they?)

[larseggert]

They are based on the plaintextified HTML using @martinthomson's CSS. (Same as is shown for HTMLized.)

[cabo]

They are based on the plaintextified HTML using @martinthomson's CSS. (Same as is shown for HTMLized.)

Yes. Again: I don't see the point to do this when we can do the real thing.

Of course, using typewriter style conceals the fact that we cannot do standard typography correctly yet.
But the disadvantages outweigh the lack of pleasance of that inconvenient revelation.

[larseggert]

As I said, we can "do the real thing". It will require the community to agree that this is what they want. Past feedback indicated they wanted PDFs of text versions.

[cabo]

Note that this isn't an alternative. We could produce both real and fake PDFs, if the latter are really needed, just like we have html and "htmlized" (which no longer is).

[rjsparks]

If we can remove codepaths and alternate representations in favor of a smaller, easier to explain set, then we should do that. But I don't think we can.

Right now we do not require submission in xml. If someone provides only plain text, we do htmlize and then pdfize that. We cannot use xml2rfc to produce html or pdf.

We can't really stop providing the -ized formats when we do have v3 xml, because that would force people (and systems like wikipedia) to have to learn to point to different types of things depending on the underlying arcana of the submission, which is really a non-starter.

So, I don't think we can make less, and I cringe at the proposal to make more because of the confusion it causes.