search

hpi-swa-lab / SqueakByExample-english

An introductory book about the Squeak/Smalltalk programming system, guiding students and developers through the environment, language, tools, and the Morphic framework by means of a series of examples and exercises.
https://www.lulu.com/shop/patrick-rein-and-christoph-thiede/squeak-by-example-60/paperback/product-8vr2j2.html
Other
24 stars 6 forks source link

Use high-dpi mode for all screenshots #137

Closed LinqLover closed 1 year ago

LinqLover commented 1 year ago

This PR changes all figure scripts to use a high-dpi mode. Currently, a scale factor of 1000% is used.

Plan (see details below)

About the scale factor

The reasoning for the chosen scale factor is: 

We assume an intended print quality of 300 ppi, which seems to widely recommended.
One page might be ~8 inches wide, corresponding to 8 * 300 ppi = 2400 ppi.
To meet these requirements, a small screenshot, 200 px wide, would require 2400 ppi/200 px ~= 10 points/pixel.

Plus, 1000% just look extremely sharp even on my high-dpi monitor when I scroll into any screenshot:

image

Performance considerations

Is this impact too large?

If yes, my recommendation would be to make the quality configurable so that we can still use the high quality for deploying the print version of the book (e.g., only when triggering a manual release through the CI).

Implementation

The key change is in https://github.com/hpi-swa-lab/SqueakByExample-english/pull/137/commits/1af076a83eac7511f7a00beaeaa16b10eb41d1de#diff-3c20f202c870e5c8070c65943b8b009add95dbfa97dd06304e4c152a68d23560 where the scale factor used during screenshotting is raised to 10. Besides, various places in the SBE-Extract logic and in the individual figure scripts are adjusted to be high-dpi-sensitive, i.e., using #px & Co. I had some fun converting the scripts semi-automatically, see the commit message in https://github.com/hpi-swa-lab/SqueakByExample-english/pull/137/commits/01d95a37dbbfd590061d24b30c93a187745bbc38 for additional details.

All \includegraphics that used scale= are rewritten to width= to eliminate the dependency on a concrete scale factor. While I checked all figures in the book again, there might be some figures that no longer have to perfect size for your taste @codeZeilen.

Regarding the Morphic examples in the book (Quinto/SBE-Morphic), they are kept free from any high-dpi-aware code for sake of simplicity. Instead, a few relevant figure scripts rescale the morphs in question manually (see https://github.com/hpi-swa-lab/SqueakByExample-english/pull/137/files#diff-8c737ffb22e03102e18ddb43a4ff377860346cfad3c78badbe05e37a4b75c5f8R49-R57 for instance).

Also, some scripts are refactored and some figures (such as QuickTour/ClassBrowser2) receive minor optical tweaking.

Depends on Morphic-ct.2047 and Morphic-ct.2048, which are already integrated into Squeak 6.1Alpha and backported to Squeak 6.0. Without these patches, some lists were scrolled incorrectly, and some halo labels were truncated.

Integrates #136. Closes #35.

LinqLover commented 1 year ago

This will take time.

LinqLover commented 1 year ago

Lol, we're getting some occasional sporadic segfaults during screenshot generation on the CI. I have already experienced some of them when working locally (totally different stack dumps, though). Maybe out of memory/some memory leak/...?

codeZeilen commented 1 year ago

@LinqLover Anything left for me to do here?

LinqLover commented 1 year ago

@codeZeilen Yes, could you maybe take a short stand to the open questions in the PR description? :) tl;dr: Should I further reduce PDF size & build times and if yes, should we have a switch for high-qualitative print builds?

LinqLover commented 1 year ago

Update: