Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font Rendering & "Save Image" Safari Issues with Waterbug #89

Open
mrworthington opened this issue Jul 14, 2017 · 0 comments
Open

Font Rendering & "Save Image" Safari Issues with Waterbug #89

mrworthington opened this issue Jul 14, 2017 · 0 comments

Comments

@mrworthington
Copy link

mrworthington commented Jul 14, 2017

Hello!

A team I'm working with has just built an instance of lunchbox on AWS and while everything else is fine, we are running into the following issues. I can't post the link to the instance publicly just yet but can share links privately to the instance. Anyway, here are the concerns:

  1. Fonts displaying incorrectly on images: with our fonts displaying incorrectly on waterbug images (see samples below). (To be clear, the unshaded text in each sample image is the rendered text from waterbug.) Because of the font we use (Whitney from Hoefler & Co.), users are directed to upload a primary and secondary version of the font. In our Quotable & Factlist instance, which load both the primary and secondary Whitney fonts from a CSS file, no problems occur. However, when we try listing both fonts in Waterbug's JS file, I get an error which prompts me to only load one.

    • Big Question: How can we load both the primary & secondary version of the font in the JS file as we do in the CSS files for Quotable & Factlist?

sample1
sample2

  1. Save Image Executing Stragely on Safari: For whatever reason, when we use Waterbug in Safari (Version 10.1.1 (12603.2.4)), pressing the "Save Image" an image executes in a very memory intensive format that I've never seen before. In short, it opens a new safari tab and appears to draw the rendered image via a very long data:image/png;base64 link that totally consumes most of the existing memory on my computer because the file link is well over 50,000 characters long. The other part of this is that in Chrome (Version 59.0.3071.115), images render normally and we can't identify issues in our Javascript that would explain why this difference exists.

    • Big Question: Has this issue been seen before and, if not, what could be the cause of this?

messages image 1068780612

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant