Subject: Fill page when printing archived threads

From: Paul A Jungwirth <[email-masked]>
Date: Mon, 19 Jan 2026 09:45:53 -0800

Hello, www folks!

When printing some mailing list threads, I wind up with mostly blank
vertical space on the page. For example this one:
https://www.postgresql.org/message-id/flat/[email-masked]
(PDF attached).

The reason is the .message-content CSS rule sets the display:
inline-block property, and that causes the paragraphs to "stick
together" more tightly than to the header or the next message.
Changing the property to "block" makes the thread print much more
naturally (sample PDF attached, also a patch).

What do you think of this change?

Btw pgweb has the same CSS rule, although it doesn't appear to be used
by anything in that repo.

I haven't tested with a locally-running copy of the site. Are there
instructions anywhere on setting that up? I'm comfortable with Django,
but I would still need a database, possibly a settings file, etc.

Yours,

-- 
Paul              ~{:-)
[email-masked]
From 89c25a6199609b164b6342e2eb66e5189735ac67 Mon Sep 17 00:00:00 2001
From: "Paul A. Jungwirth" <[email-masked]>
Date: Mon, 19 Jan 2026 09:30:31 -0800
Subject: [PATCH v1] Fill pages better when printing mailing list archive
 threads

The .message-content CSS rule applied a display: inline-block property,
but this caused all text of a message to stick together more tightly
than to the header or the next message, making pages print with large
empty spaces. By using display: block, we allow paragraphs to split
normally.
---
 django/media/css/main.css | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/django/media/css/main.css b/django/media/css/main.css
index f7d6646..2e356e7 100644
--- a/django/media/css/main.css
+++ b/django/media/css/main.css
@@ -772,7 +772,7 @@ h3.messages {
 }
 
 .message-content {
-    display: inline-block;
+    display: block;
     font-family: monospace, monospace;
     font-size: 0.7em;
     line-height: 1.2em;
-- 
2.47.3

---

From: Christoph Berg <[email-masked]>
Date: Fri, 23 Jan 2026 11:17:22 +0100

Re: Paul A Jungwirth
> but I would still need a database, possibly a settings file, etc.

docs/dev_install.rst is pretty good.

Christoph

---

From: Paul A Jungwirth <[email-masked]>
Date: Wed, 11 Feb 2026 14:32:40 -0800

> docs/dev_install.rst is pretty good.

Thanks! My change is actually for the pgarchive repository, but I
think you're talking about the instructions for pgweb.

I did get pgweb running locally though. (It required some surprising
changes to requirements.txt, which I'll submit separately.) When I
click on the left nav's "Mailing Lists" link it goes to
http://localhost:8000/list/ which is a 404. So I guess postgresql.org
must be tying these together behind a reverse proxy. I still haven't
found any instructions for getting pgarchive running locally, but I'll
experiment a bit.

Yours,

---

From: Magnus Hagander <[email-masked]>
Date: Thu, 12 Feb 2026 13:05:02 +0100

> found any instructions for getting pgarchive running locally, but I'll

That's correct, the /list/ namespace is proxied.

The whole handling of templates between them is a mess (one has to remember
to manually copy the base template between two different repos when
changed), and we should really find a better way to handle that. But that
is how it is now.

FWIW, locally I just run pgarchive on a different listener and ignore that
the link in the menu doesn't work and have a bookmark that point directly
to it.b

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ <http://www.hagander.net/>
 Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

---

From: Paul A Jungwirth <[email-masked]>
Date: Thu, 12 Feb 2026 08:11:16 -0800

On Thu, Feb 12, 2026 at 4:05 AM Magnus Hagander <[email-masked]> wrote:
> The whole handling of templates between them is a mess (one has to remember to manually copy the base template between two different repos when changed), and we should really find a better way to handle that. But that is how it is now.
>
> FWIW, locally I just run pgarchive on a different listener and ignore that the link in the menu doesn't work and have a bookmark that point directly to it.b

Okay, that was pretty much my plan too.

My initial motivation is to improve printing mailing list archives. So
my patch changes a CSS rule in pgarchive. But when I look at an
example page from the archives [1] vs an example page from the About
section [2] they both reference the same CSS URL [3] (albeit with a
different cache-busting hash). So I'm guessing that really comes from
pgweb? Maybe the CSS files in pgarchives should be removed. Or perhaps
they are convenient for running it in dev? A diff between each
project's main.css shows a lot of differences, so I guess you aren't
syncing them like the base template.

Are there any big-picture improvements you'd like to make here that I
could help with? For instance maybe pgarchive should be a separate
Django app within the pgweb project. (I think that would likely call
for moving settings.py and wsgi.py to the top level.) Or just roll it
into pgweb entirely. Or if we're keeping them separate, maybe I could
at least write some documentation about how to set up a dev copy of
pgarchives, and how to integrate it with pgweb (copying templates,
sharing css, etc).

[1] https://www.postgresql.org/message-id/CAKFQuwb0Q655=EYRdpKaVoES9uDbZ3RdWn3=[email-masked]
[2] https://www.postgresql.org/about/featurematrix/
[3] https://www.postgresql.org/dyncss/base.css

Yours,

---

From: Magnus Hagander <[email-masked]>
Date: Fri, 20 Feb 2026 20:18:52 +0100

On Thu, 12 Feb 2026 at 17:11, Paul A Jungwirth <[email-masked]>
wrote:

> > The whole handling of templates between them is a mess (one has to
> remember to manually copy the base template between two different repos
> when changed), and we should really find a better way to handle that. But
> that is how it is now.
> >
> > FWIW, locally I just run pgarchive on a different listener and ignore
> that the link in the menu doesn't work and have a bookmark that point
> directly to it.b
>

Yeah, I think that's the problem - a lot of fixes have been applied only to
one side, and that's led to a lot of divergence over time.

> pgarchives, and how to integrate it with pgweb (copying templates,

We don't want to integrate it to that level, because we have external users
of the archives code that don't use pgweb at all. And we have our own
private archives, which aren't linked in under the same hostname and runs a
completely independent instance.

I'm thinking maybe something along the line of having a way to point
template directories at pgweb and have it pick up changes from there if
they show up, but still operate with built-in templates if iit doesn't. And
then we could reduce the built-in ones to not be as heavily postgres
branded. And the same for media files like css and js of course.