I need some advice how to fix the "overfull \hbox" errors. It seems to say that the resulting text would need too much space in horizontal direction. OK, let's look at the first case "lines 3154--3160": How is it possible to edit the text to make it even smaller?

For reviewing, it's not helpful that the PDF isn't uploaded because the output check failed.

For reviewing, it's not helpful that the PDF isn't uploaded because the output check failed.

I suspect this is not something I can fix, right?

Regarding my text changes: I tried to follow the pre-existing line-break structure. Maybe I shouldn't and I should try to provide each paragraph as filled line with breaks at around 70 characters?

I need some advice how to fix the "overfull \hbox" errors.

If you built it locally, you can look at which syllable a word overfills.
You can guess where the margin is by looking at the surrounding text.
Then you can just add a \- in front of the syllable closest to the margin that isn't part of the overfill.

If you built it locally, you can look at which syllable a word overfills.

Hmmh, I'm on Windows and I'm not sure how to setup my infrastructure to create the pdf locally.

If there is no other way I need to experiment with my PULL request.

I suspect this is not something I can fix, right?

I don't think you need to, as it is a separate problem.

Regarding my text changes: I tried to follow the pre-existing line-break structure. Maybe I shouldn't and I should try to provide each paragraph as filled line with breaks at around 70 characters?

The source line breaks are independent of the rendered text.
https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines#latex-source-code-formatting says

Use semantic line breaks in LaTeX source code: http://sembr.org/ and http://rhodesmill.org/brandon/2012/one-sentence-per-line/

which I wish was more strictly applied.
Those sources explain the difference well.

To get the PDF uploaded,
you can edit https://github.com/cplusplus/draft/blob/main/.github/workflows/check.yml
and swap the last two steps ("check-output.sh" and "upload PDF") at the end of the file.

To get the PDF uploaded, you can edit https://github.com/cplusplus/draft/blob/main/.github/workflows/check.yml and swap the last two steps ("check-output.sh" and "upload PDF") at the end of the file.

But isn't that a setting that should be independently set from my PULL request?

To get the PDF uploaded, you can edit https://github.com/cplusplus/draft/blob/main/.github/workflows/check.yml and swap the last two steps ("check-output.sh" and "upload PDF") at the end of the file.

But isn't that a setting that should be independently set from my PULL request?

No. In general, I think we can expect someone editing the draft to be able to build locally before uploading. And we only want "good" artifacts published from our continuous integration pipeline.

I've redone the patch: #6519

It keeps the semantic linebreaks and removes "The argument/parameter" fluff entirely, which is consistent with at least half of the occurrences.

I've redone the patch: #6519

Thanks for your help.

To get the PDF uploaded, you can edit https://github.com/cplusplus/draft/blob/main/.github/workflows/check.yml and swap the last two steps ("check-output.sh" and "upload PDF") at the end of the file.

But isn't that a setting that should be independently set from my PULL request?

No. In general, I think we can expect someone editing the draft to be able to build locally before uploading. And we only want "good" artifacts published from our continuous integration pipeline.

A fine alternative if one doesn't want to build it locally, or can't, is to do it in one's own fork.
Just enable GitHub Actions there.
In case the branch already has a PR for origin,
branch again to create a playground that doesn't make noise on that PR for origin,
then, once the PDF looks good, hard-reset the PR's branch to its rebranch and force-push.

This can be closed, as it's subsumed by the merged #6519.