Use high-dpi mode for all screenshots #137
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adapting all screenshots for high-dpi aware dimensions is yet to come ...
This did it:
| matcher files |
matcher := '%%\{(SBESqueakPicture)(([^\r\n]*([\r\n]|\r\n))%%)*(])\}' asRegex.
files := SBEScriptBuilder getTexFilesIn: SBEScriptBuilder resourceDirectory.
files
collect: [:file | file -> (SBEScriptBuilder collectScriptsFromFile: file)]
as: Dictionary.
files do: [:file |
file writeStreamDo: [:stream | | translated |
translated := matcher copy: file contents translatingMatchesUsing: [:s | '\begin{ExecuteSmalltalkScript}' , (matcher subexpression: 5) , (((matcher subexpressions: 2) , (matcher subexpressions: 4) , (matcher subexpressions: 6)) join) , (matcher subexpression: 5) , '\end{ExecuteSmalltalkScript}'].
stream reset; nextPutAll: translated]]
Regex:
SBESqueakPicture( writeTo: .* (frame: .* ))using:(?= \[)
->
SBEScreenshotRecorder$1building:
|
This will take time. |
…SBEFigureBuilder class>>#buildFiguresWith:)
This did it (thanks Copilot!):
> const fs = require('fs')
> const path = require('path')
> const glob = require('glob')
> const replace = require('replace-in-file')
> var options = {
files: glob.sync('**/*.tex', {ignore: ['**/node_modules/**']}),
from: /(?<=\\begin\{ExecuteSmalltalkScript\}((?<!\\end\{ExecuteSmalltalkScript\})[\s\S\n\r])*(?<!(fraction:(\s*\d+(\.\d+)?\s*@\s*)?|crtab:|selection:|selectAt:|to:|by:|\/|\*|[<>])\s?)(?<!-|-?\d+\.\d*)\(?-?\d+(\.\d+)?(?! px)(?!(\d*\.)?\d))(?!\.png)(?![\}'"])(?!\s*to:)/gi,
to: ' px',
}
> replace.sync(options)
In high-dpi mode, saving of scenes may actually take more than 5 seconds.
…positions and tails
Basically, we must not use \includegraphics.scale any longer to avoid assumptions on the current scaleFactor for the screenshots.
Exclude very slow #testPercentEncodingJa.
dynamic names are possible but hard to read
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Plus, 1000% just look extremely sharp even on my high-dpi monitor when I scroll into any screenshot:
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).
SBEWorldHelper class>>#scaleFactordynamic. But this increases the risk for unexpected figure slips that only occur for certain scale factors, as I have met some while migrating for this PR. I have not yet further spiked this.Implementation
The key change is in 1af076a#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 01d95a3 for additional details.All
\includegraphicsthat usedscale=are rewritten towidth=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.