All of the screenshots are illegible because a width="100%" property
is set in each <img> tag, causing them to be stretched and introducing
significant aliasing. Resizing the browser window to a smaller size
does not help much. Due to the low resolution of the images (484x316)
and small size of the text, even minimal scaling causes blurring and
aliasing. The text, though small, is completely clear and legible when
the images are rendered at their native resolution.

This is the case in the HTML help installed to
/usr/share/doc/aptitude/html/en by the aptitude-doc-en package, as
well as the online version.

Please view for an example:
https://www.debian.org/doc/manuals/aptitude/ch01s01s01.en.html

I suggest removing the width='100%' property from each of the the
<imagedata> tags in the DocBook XML source (/doc/en/aptitude.xml) or
adding an img selector in the CSS stylesheet (/doc/aptitude.css) with
a width:auto property, which will override the the HTML <img> tags.

Hi Joshua,

thanks for the bug report.

Joshua C. Lackey wrote:

I can confirm that they are stretch to full width.

I though unfortunately (or luckily, depending on the point of view ;-)
can't reproduce this in Chromium from unstable. Even in fullscreen
mode on a 1900x1200 screen, they're crisp, sharp and very readable for
me, but of course also very pixely.

Sounds like a potential browser bug to me. Scaled images should never
be more blurry than unscaled images. They just should be more pixely.

In which browser did you have that effect? Maybe you can make a
screenshot of the issue, too.

Same for me in any scaling, i.e. I can't reproduce this. :-/

While I do see that this at least would solve the issue described
above, I'm reluctant to actually do this as it would introduce
legibility issues on big screens with high resolutions for some people
due to the (as you noted) rather small resolutions of the pictures.

The only clean solution for this which comes to my mind, is to redo
all the screenshots in some terminal with scalable fonts and do
vectorised SVG screenshots, e.g. with gtk-vector-screenshot.

Just tried this, but defacto, there's a PNG inside the SVG, at least
when trying inside lxterminal or gnome-terminal. :-(

Another idea is to use aha (https://github.com/theZiz/aha), but this
is non-trivial with a TUI application and only usable in HTML, not in
PDF, etc. We though could let them render in a browser and take a
vector screenshot of that.

If I do a "hardcopy" in screen and pipe that file through aha, the
layout is fine, but it doesn't catch the ANSI colors.

Piping the saved transcript of "script -c aptitude" through aha messes
with the indentation, but keeps the colors.

Best result (but still unusable) so far was with:

$ printf '[qy\n' | aptitude | aha > aptitude.html

But actually the "[" had no effect.

asciinema might also be an option, too, but that's usually for videos
not for pictures. But we could freeze a frame and take a vector
screenshot then.

		Regards, Axel

With respect to asciinema: I found two asciicast to svg converters:
 - https://github.com/marionebl/svg-term-cli (MIT)
 - https://github.com/nbedos/termtosvg (BSD-3-Clause)

Both generated an animated svg by default, but have an option to extract
a single frame (svg-term-cli), or all frames (termtosvg). I found that
termtosvg rendered aptitude better than svg-term-cli.

I also tried the Secure Shell chrome extension (which uses hterm
internally, both nassh and hterm as BSD-3-Clause), and while it's
possible to capture a decent screenshot with it, the output is html and
not svg.

I'm not sure how much switching to svg would help overall. Removing the
100% width would probably help the most. Refreshing the images at a
higher resolution wouldn't hurt either. Both are easier than trying to
change the image format.

Regards

Norman

Hi Norman,

thanks for sharing your thoughts and experiments on this issue.

Norman Rasmussen wrote:

This seems not packaged in Debian so far.
https://packages.debian.org/search?keywords=termtosvg

It's also the only option from these two as of now. :-)

The latter is no issue, but IMHO even a feature. The need to use a
Chrome extension is though a complete no-go.

Actually rather than SVG I'd rather use "aha" to generate HTML from
terminal output. An example is attached although the foreground on the
cyan lines should be black, not grey. (Not sure if this is a bug in
aha or if it is caused by myself removing some additional content
caused by the screen session around it.) So IMHO it currently would be
worse than what we have now.

It's though not completely trivial to trick a TUI application to pipe
output into aha without making it recognize that the output is not a
terminal. "script" and "screen" help there, but it's still non-trivial
to actually script it (in case that's wanted and needed — at least
currently it's not needed).

While it might help in this case, I fear that it will cause other
readablity issues like being unreadable for those who require larger
fonts.

Yes, but only if you also use some larger font. Otherwise the
situations gets worse.

Well, if we want to stay with images, SVG is IMHO the way to go. The
question is if HTML screenshots are not even better for e.g. blind
people because they're actually "readable screenshots". And they're
scalable, too.

		Regards, Axel

I guess in this case a HTML "screenshot" is really the best as there are
no fancy graphics you would need to catch the shape of but all glyphs
found in a font – which in SVG would usually need to be converted to
shapes which can be scaled, but do not have hinting and such (although
that might lead to differences between screenshot and reality if the
renderer chooses to perform different hinting, ligatures or whatever).

I think this document can be rendered in other formats than HTML though,
so you might need something for that case, too. Also, the second
screenshot on the example given in the bugreport with the opened menu is
probably not that understandable if a screenreader would read that out,
so screenshots will probably still need an explainer even if they can be
technically read… I am not blind though, so I can't really judge that
with certainty.


Anyway, the 100% was probably chosen for displays smaller than the
screenshot as the user would need to do horizontal scrolling then.
I guess I would use the equivalent of

```css
.screenshot { text-align: center; }
.screenshot img { width: 100%; max-width: max-content; }
```

in the document so that the screenshot isn't scaled into oblivion on
(very) width screens. This still allows users to zoom the page which
will also zoom the images. Meanwhile on small screens no horizontal
scrolling is needed and on wide screens no scaling is performed by
default (and due to the first line the image is centered on the page
because I personally prefer that style…).


Best regards

David Kalnischkies

```css
.screenshot img { image-rendering: crisp-edges; }
```
which might be helpful regardless of adopting the previous stanza as it
hints the renderer to not use a "smooth" scaling algorithm more suited
for normal pictures and instead be more pixely which looks more like
a terminal would look like.

Different browsers use different scaling algorithms and different
heuristics if left to their own devices which could explain why the
initial reporter saw blur while Axel isn't.


Best regards

David Kalnischkies