Grey boxes / shadows around blockquotes (Mac Preview)

[adroste]

As described here: https://old.reddit.com/r/homebrewery/comments/ch3v0d/psa_grey_boxesshadows_around_notes_stat_blocks_etc/

This issue is still a thing. OS: macOS 11.5.1 Chrome: 92

Seems like certain renderers like the macOS Preview App still have problems with the exported box-shadows.

Stupidly, if I replace the box-shadows with a drop-shadow filter, everything renders fine in every PDF App I have:

.phb blockquote {
	/* workaround for grey boxes around blockquotes */
	box-shadow: none; 
	filter: drop-shadow(2px 4px 6px #888);
}

Same holds for other elements using box-shadows like elements with the class descriptive:

.phb .descriptive {
	box-shadow: none;
	filter: drop-shadow(0 0 6px #faf7ea);
}

[calculuschild]

This is a known bug in Mac Preview; it struggles a lot with partially transparent elements in a lot of cases. Unfortunately we do not have any affiliation with Mac to be able to fix the problem on their end.

The solution... Is to not use a buggy app to view your PDFs.

If you insist on using Preview, you can take a look at thia post for some workarounds:

https://www.reddit.com/r/homebrewery/comments/jx6e42/green_side_note_gets_an_ugly_blackish_border_once/?utm_medium=android_app&utm_source=share

Chrome is also working on a possible workaround but I wouldn't hold your breath.

https://bugs.chromium.org/p/chromium/issues/detail?id=995265

[adroste]

Sure. It's definitely a bug in Preview. Nevertheless, it can easily be fixed by changing every box-shadow to a drop-shadow. It's a fast and easy change and it won't make a difference visually. The only issue I see that could arise when performing such a change could be an incompatibility to some existing "brews". "Brews" where authors already changed the visual appearance of the shadows by injecting own styles.

[Gazook89]

The only differences between box-shadow and filter:drop-shadow are no ability for "inset" shadows and one less distance parameter in drop-shadow. Likely true that any place that uses box-shadow right now could instead use drop-shadow. But haven't tested. Couldn't be done in Legacy due to breaking brews, but v3.

[calculuschild]

@adroste There is pretty apparent visual difference between box shadow and drop shadow. Box shadow extends around the top and bottom, but drop shadow does not. This is not something we are going to change to accommodate someone else's bugs. And you do bring up another good point that making changes like this has the potential to break existing brews.

However, as you have noted, you can manually change the shadow behavior on a per-brew basis by adding custom CSS to your document. If you are satisfied with that appearance, you can make that adjustment on your own brews via the Style tab. That's what it's for after all! :+1:

[Gazook89]

Oddly, I don't get this issue on macOS 11.5, Preview 11, printing to PDF from Chrome. Box-Shadow is just fine for me.

But why not make an adjustment for v3? Drop-shadow can extend all the way around an element if the spread is larger than the offset drop-shadow(0 0 6px) for example. Further, the current box-shadow doesn't extend all the way around the box due to it's offset...the first note is the default box-shadow, and the second has drop-shadow:

The only visible difference is that drop-shadow follows the contour of the alpha channel on the border image, where box-shadow does not (only follows the edge of the elements box). Arguably, this is a point in favor of drop-shadow.

Changing it for legacy wouldn't work, but adusting for v3 before any brews exist would be a non issue....seems like the time to squash this issue.

[calculuschild]

Ehhhh... maybe for v3. It looks pretty close. How well does it work for our other shadowed elements? (monster stat blocks, etc.)

[Gazook89]

I was trying to think of other shadowed elements and forgot monster blocks, but I don't think there is anything else...? Not class tables, not descriptive boxes....

[adroste]

@Gazook89 Descriptive text boxes also have a white-ish box shadow: box-shadow: 0 0 6px #faf7ea;

[Gazook89]

See PR #1577

[calculuschild]

We went ahead and changed to drop-shadows in the V3 branch. I think this should also be fine to add to the Legacy styling since it will only change appearance (very slightly) but positioning and sizing of elements should be the same. I.e., old brews shouldn't "break".

@Gazook89 Do you want to cook up another PR to apply this to Legacy as well? (I probably should have just had you add to #1577 but didn't think about it until now)

[calculuschild]

Following the issues encountered in #1661 , we might need to undo the changes to V3 back to using box-shadows since drop-shadow makes text unselectable and corrupts image quality.

This actually seems to make things objectively worse. I'm also thinking we might want to go back and undo the change to V3 as well. Selectable text and good image quality in almost every PDF viewer is preferable to just catering to the weird edge case in Mac Preview.

[lucastucious]

I have undo the changes in my pull request : #2127

[adroste]

@calculuschild Did some further research and it's true, the drop-shadow works because chrome will print the box as an image with transparency. This reduces the visual quality of the text and prevents selection. A fix suggested here (https://github.com/puppeteer/puppeteer/issues/5284#issuecomment-727826838) just applies a filter property document-wide resulting in a pdf consisting of screenshots 👎.

With all the introduced trouble in mind, I think there is a reasonable way to "properly" misuse the filter property. If you move the box-shadows to another layer (e.g. with absolute positioning) and apply a noop-filter, you end up with pdf where the shadow is overlayed as graphic with the border-image but the text content remains selectable text/vector.

.phb blockquote {
  box-shadow: none;
  position: relative;
}

.phb blockquote::after {
  content: '';
  position: absolute;
  /* border-width = 11px, could be set as css variable */
  left: -11px;
  right: -11px;
  top: -11px;
  bottom: -11px;
  box-shadow: 1px 4px 14px #888;
  /* force chrome to print shadow as graphic */
  -webkit-filter: opacity(1);
}

[calculuschild]

@adroste This is an interesting approach. Unfortunately, there are already a few cases where the after (and before) pseudoelements are already claimed for other purposes. We might be able to redesign those elements to make this work, but in the meantime I think we may need to go back to box-shadows with #2127, and direct users to instead report the issue to Apple so they can fix the source of the bug in Preview.

[adroste]

The shadow must just be applied at another level. It must not be via ::before or ::after. It can be any element anywhere as long as you keep track of the positioning and border of the container-element you want to create a shadow for. This is especially easy if you apply the styling on a nested absolute positioned element with the container set to relative. This way the solution could be css only.

Apple will fix s***. I'm reporting bugs my whole life and they just don't care. There are certain security related issues that Apple introduced in macOS 12.0 that still are not fixed yet despite new daily reports from other community members. If something does not work in the Apple world you have to find a workaround yourself or ignore it.

When it comes to macOS/iOS/iPadOS Preview is the only 'good' PDF viewer. Acrobats rendering might be more correct, but the UI and performance is broken since Steve introduced Retina displays in 2012/2013. Additionally, the preview renderer is deeply integrated into every part of every OS: Safari on macOS, all web browsers on iOS/iPadOS, QuickLook, Finder, Files etc.

To sum it up, Homebrewery PDFs are broken on every Apple device. We all know it's Apples fault, but they will not fix it. We can just try to make the Homebrewery rendering more compatible with simple hacks like the one mentioned above.

[calculuschild]

It can be any element anywhere as long as you keep track of the positioning and border of the container-element you want to create a shadow for.

Right, but then this involves introducing nested elements everywhere you want a shadow. Rather than <div>Content</div>, now the text editor becomes cluttered with <div><div class="shadow">Content</div></div>. That's putting more burden Homebrewery users where before/after allow the shadow to be "built-in" to the element. Not to mention breaking shadows on all existing brews because users will now need to update them by manually nesting a shadow in every block.

[adroste]

Absolutely. I just looked at #2127. If it's just about these 4 places, it should be fairly easy to implement and test:

• The before pseudo element is not used for the note, descriptive text box and monster stat block.
• The class-table decoration has a shadow directly on the before pseudo element to darken the background image. This shadow does not affect any text or content and therefore must not be changed. For the sake of consistency it could also safely be changed to a box-shadow + noop filter without a noticable effect.

[Gazook89]

Is this still an issue? I noted way back when that I did not have the same problem with gray borders in Preview on my Mac that @adroste had, but I'm just coming back around to see what issues and PR's can be closed (this and #2127).

For my brews created in Chrome on MacOS, viewed in Preview....

With Drop-Shadow

With Box-Shadow

The filter:drop-shadow(); still prevents text selection. So if box-shadow issues (gray boxing) are no longer present, then my vote is to switch back to box-shadow.

[calculuschild]

Fixed by #2127 .

Upon further investigation, it's not the Preview PDF viewer with the issue, but rather the built-in Mac PDF generation that Chrome defaults to using.

As of Mac Preview v11, the gray box issue is no longer occurring. Thus, we have switched back to using box-shadow since filter:drop-shadow makes text unselectable.

As a workaround, any Mac user still experiencing the gray box issue can create their PDFs on another machine that has a newer Mac version or uses Windows.

[Gazook89]

Just a note for future readers: another alternative is to just go back to using drop-shadow and unset the box-shadow.