Grey boxes / shadows around blockquotes (Mac Preview)

adroste commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

Gazook89 commented 3 years ago

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 commented 3 years ago

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

Gazook89 commented 3 years ago

See PR #1577

calculuschild commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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

adroste commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

sussman commented 4 months ago

Running into this bug -- using absolute latest MacOS 14.4.1 on absolute latest Macbook (M3-Max, a month old.)

You can read about the details on my reddit post.

I tried 'fetching' the PDF on Chrome on Windows 11, and it doesn't help -- the same troublesome box-shadow tag is present, and every MacOS PDF renderer still can't render it properly.

The point of my posting here is that the comment from @calculuschild is no longer true: using the latest MacOS doesn't help, and using Windows doesn't help. You may want to re-open this issue.

sussman commented 4 months ago

@Gazook89 can you post some CSS that shows a workaround -- i.e. exactly how to go back to drop-shadow in the style-editor? I'm not a CSS guy. :-)

5e-Cleric commented 4 months ago

We have not found any evidence so far that this issue happens outside of mac preview, but if what you say is true this is a major problem.

Could you send a share link or code snippet with this issue? for testing purposes.

If we still find this issue, we will probably need to swap box shadow for a drop shadow, even though that in itself has other problems

calculuschild commented 4 months ago

If we still find this issue, we will probably need to swap box shadow for a drop shadow, even though that in itself has other problems

Just for the record, we will not be switching back todrop-shadow. We already tried that. While it fixes this one issue limited to a specific Preview bug, it creates other issues that appear on every platform.

See https://github.com/naturalcrit/homebrewery/pull/1661

sussman commented 4 months ago

Hey all, I have a minimal test case that showcases the Mac bug!
It's some sort of weird interaction between a {{ div }} block, and the {{ note }} and {{monster}} blocks.

Reproduction recipe:

Create a single page that has a div, followed by a note. Example here. It looks totally fine during live-rendering, on both Mac and Windows. (In the example, the div block has some attributes, but this bug happens even with just a plain {{ ... }} div.)
'Get PDF' and download the PDF.
The resulting PDF looks broken in the absolute latest MacOS -- there's a grey block behind the note, blocking text.

Note that this bug above happens when generating the PDF on both Mac and Windows Chrome. The PDF always looks fine in Windows, but both are broken when viewing on Mac. In other words, the workaround of "just fetch the PDF from Windows Chrome and then send to your Mac" doesn't help here.

Further investigation:

Two divs back to back -- the bug doesn't happen.
Two notes back to back -- the bug doesn't happen.

It's something specific about div, followed by note.

5e-Cleric commented 4 months ago

Note that this bug above happens on both Mac and Windows Chrome.

Windows 11 with Chrome 124:

calculuschild commented 4 months ago

@5e-Cleric I modified their comment for clarity. What they mean is, the PDF still appears broken on Mac, even if originally generated on Windows.

calculuschild commented 4 months ago

So obviously it's a Mac bug.

Yes. The PDF is generated correctly in either case (I can view his Mac-generated PDF on Windows and it looks fine), but Mac fails to render the shadow. So specifically a Mac viewing issue.

Gazook89 commented 4 months ago

@sussman Are you opening the PDF in Preview? Have you tried any other PDF viewers?

Mac Preview

I have a Mac as well, so just pasting the result of generating on MacOS Chrome and viewed in Mac Preview (not that we need yet another example, but just so i don't have to scroll to the top):

Mac Adobe Acrobat Reader

However, when opening the same file in Acrobat, I don't have the issue:

Mac Chrome (viewing as PDF file)

And similarly if I open the pdf file in Chrome, it renders correctly:

So I think this is squarely a Preview issue. Edit: Which is at odds with this declaration in this earlier comment but maybe things have changed, or it was incorrect.

calculuschild commented 4 months ago

That earlier comment stems from this discussion on Gitter: https://app.gitter.im/#/room/#naturalcrit_Lobby:gitter.im/$BzzlvUIGmeBPFcdLuPqK60wGy-XmgI5bvRLO2xy2bKE

Could be we missed something there.

In any case, it looks like Google already narrowed down this cause in this comment. I don't think we can necessarily do anything about it. https://issues.chromium.org/issues/41476907#comment33

sussman commented 4 months ago

At this point, I'm trying to figure out how, after building a 20 page module in homebrewery, I can create a PDF that works everywhere. I don't even know how to work around this. :-( MacOS Preview isn't a 'niche' set of users.

Gazook89 commented 4 months ago

Possibly you could run it through a pdf optimizer and get better result to share. I haven’t tried it

sussman commented 4 months ago

Hey all! Pinging here again, wondering if I can persuade devs to reopen and work on this issue again. To recap:

Any time a {div} and a {note} are on the same page, the resulting PDF isn't rendered correctly by MacOS Preview (or any of the zillion things that depend on the MacOS-level PDF rendering code).
It doesn't matter what OS or browser the PDF in generated from; it always renders broken on Mac.
This doesn't seem like an obscure edge-case to me. Mac-users aren't a teensy minority like they were 25 years ago. :-)

I completely agree that this is Apple's bug, not Homebrewery's. But my gut says there must be some sort of HTML/JS/CSS workaround that can be inserted temporarily, just as you did before.

I'm a software dev myself and have run many open source projects, so of course I know how ridiculous it is that anyone "demand" that a bug be fixed. I should submit a patch myself! But sadly, I'm a backend engineer, and my knowledge of JS/CSS is pretty rudimentary. :-( That said, let me know if there's anything I can do to help. Maybe I can lend one of you a Mac for testing? :-)

5e-Cleric commented 4 months ago

@sussman This is a Mac issue, the only thing we could do in our own is to delete shadows entirely. This issue will not be fixed by us, you can fix it by yourself changing the box shadows to filter drop shadows (i think) but we won't do that fix because it causes other minor issues.

This issue will remain closed until a new option is available.

sussman commented 4 months ago

Thanks for the explanation. Can you explain to me how I can change box shadows to filter drop shadows? Or point to an FAQ perhaps? (I'm also curious what sort of minor issues it causes!)

calculuschild commented 3 months ago

Thanks for the explanation. Can you explain to me how I can change box shadows to filter drop shadows? Or point to an FAQ perhaps? (I'm also curious what sort of minor issues it causes!)

Look at this PR for the changes and the subsequent issues that arise, causing us to revert the changes: https://github.com/naturalcrit/homebrewery/pull/1661

naturalcrit / homebrewery