Keep the cover image's Opaque choice through the Edit tab and the thumbnail (BL-16819) - #8339
Merged
Merged
Conversation
JohnThomson
commented
Sep 10, 2026
JohnThomson
commented
Sep 10, 2026
Contributor
Author
|
[Claude Fable 5.1] Consulted Devin on 2026-09-10 up to commit a938879. Three rounds. Devin raised two bugs, both fixed and both marked resolved by its final pass: an Auto JPEG cover still skipped transparency in the collection thumbnail (#8339 (comment)), and the thumbnail's transparency temp file was named after the cover image so concurrent thumbnails could collide (#8339 (comment)). No Investigate or Informational flags in any round. The pr-automation check passed on every commit. |
…mbnail (BL-16819) https://issues.bloomlibrary.org/youtrack/issue/BL-16819 The first fix (#8331) restores the bloom-opaque / bloom-transparent classes on the cover image from the data-div whenever the xmatter is regenerated. That survived reopening the book and switching books, but entering the Edit tab still reset the image to Auto, and the next save wrote the loss into the book file. The book's thumbnail in the collection also ignored the choice. Entering the Edit tab calls Book.SetMultilingualContentLanguages, which pushes the member _dataset back onto the pages with UpdateDomFromDataset(). That data set is the snapshot taken when the BookData was built; when a page is saved, UpdateSingleTextVariableInDataDiv recreates its entry for the cover image with the new value but no attribute list. RestoreImgClassesFromDataDiv read the missing list as an empty class list and removed the class. - RestoreImgClassesFromDataDiv leaves the image alone when there is no attribute list, matching MergeAttrsIntoElement, which already treats null as "no information". - BookThumbNailer.CreateThumbnailOfCoverImage decides transparency with HtmlDom.GetImageTransparencyMode, so the collection thumbnail honors Opaque and Transparent instead of always running the line-art check. Auto and Transparent both work for a JPEG cover: ImageUtils.MakeTransparentBackground re-saves a non-PNG source as PNG (only a PNG can carry the alpha channel), and MakeTransparentBackgroundIfNeeded reuses it after the line-art check, which accepts JPEGs just as the editor's display path does. The transparent copy is written to a randomly named .png temp file so thumbnails made at the same time cannot collide, and a failure in that step is logged and the thumbnail is made without transparency. RuntimeImageProcessor.MakePngBackgroundTransparentIfDesirable has no remaining callers and is removed. Tests: BookDataTests cover UpdateDomFromDataset() straight after construction and after a save that set the choice (the latter fails without the fix, with an empty class attribute). BookTests cover the BringBookUpToDate round trip including the page as prepared for editing. BookThumbnailerTests check a pixel of the thumbnail for each of the three choices on PNG and JPEG covers; the Opaque cases fail without the fix. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
JohnThomson
force-pushed
the
BL-16819-cover-opaque-edit-tab
branch
from
September 10, 2026 15:46
a938879 to
9a7b1ce
Compare
JohnThomson
marked this pull request as ready for review
September 10, 2026 15:46
andrew-polk
approved these changes
Sep 10, 2026
andrew-polk
left a comment
andrew-polk
left a comment
Contributor
There was a problem hiding this comment.
@andrew-polk reviewed 7 files and all commit messages, and resolved 2 discussions.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on JohnThomson).
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Problem
Setting the front cover image's Transparency to Opaque (or Transparent) still did not stick after the first fix (#8331). The choice survived quitting and reopening Bloom and switching between books in the Collections tab, but the moment the book was opened in the Edit tab the cover image was back on Auto, and the next save wrote that loss into the book. The book's thumbnail in the collection also ignored the choice: a line-art cover marked Opaque was still drawn with its white background made transparent.
Cause
Every time the Edit tab is entered, Bloom re-applies the book's content-language choice, which pushes
BookData's member data set back onto the pages. That data set is a snapshot taken when the book was loaded; when a page is saved, its entry for the cover image is recreated with the new value but without the saved attribute list. The class-restoring code added in #8331 read a missing attribute list as "no classes" and removedbloom-opaquefrom the image.The collection thumbnail is composed straight from the cover image file, and that code always ran the line-art transparency check without looking at the image's classes.
What the PR does
BringBookUpToDateround trip including the page as prepared for editing, and a pixel-level check of the thumbnail for each of the three choices on PNG and JPEG covers (the Opaque cases fail without the fix).Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16819
🤖 Generated with Claude Code
Devin review
This change is