-
Notifications
You must be signed in to change notification settings - Fork 1
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
v1.2 font handling and output goals #127
Comments
Would reverting |
I do not believe that we currently rely on the assumption that a user can access it. The only case that I can think of where it would be relevant right now is colors - if a user wanted to use 'blackish' for anything that is not configured to use it by default. I know that in some of my personal implementations of cmapplot I would use additional colors, if we got them from Comms (i.e., if there were a specific light gray that we were supposed to use for fainter gridlines). However, if shifting to an environment has other benefits, I think that it would make sense to do so. We could then potentially add a separate export for colors (and maybe font sizes?), as those are the ones where there could be value in the users having access? |
However, the point I made in #117 stands - I do think that we should be careful about introducing the ability to monkey around with font sizes, if that is something that the Comms team feels strongly about otherwise. |
Here's another resource on environments within packages that I just added to my original post above. They write:
Seems to me that shifting to an environment could allow for basic fetch and set functions could be added using Maybe this is not relevant or important -- I am open to that, and to just leaving this all as a list. I do appreciate @dlcomeaux's point about being careful about giving users too much control (although I'm not sure I totally agree, as our users are few and in general know what they are doing). I included it here only because this font work opens an easy opportunity to make the conversion if we think there's reason to do it. But, if y'all don't think there's reason to, I'm definitely happy to be outvoted. I agree with @dlcomeaux that if we ever program cmap colors more universally into the package (like, the whole palette, rather than just |
Also, as an FYI, ggplot2 uses an environment and set/get functions for global variables: https://github.com/tidyverse/ggplot2/search?q=ggplot_global |
Thanks for putting all these links together @matthewstern. I see that ragg does not have a bmp export option - are we sticking with grDevices for this? Do folks use .bmp? I read it's not used much these days. |
I'm personally of the opinion that PNG is the only raster format we should support/encourage. BMP files tend to be much larger, and JPG compression creates awful artifacts on graphics (it's great for photos, though). |
@sarahcmap, 100% don't need to maintain support for bmp, we just did that bc it was available and worked the same. To that end, my default here would be to continue to support png, tif, and jpg via ragg, but I can get with @nmpeterson 's perspective on this and support png only. Either is fine by me! |
I don't have an issue with continuing to allow any raster formats supported by ragg, but I do think we should be explicitly recommending only PNG for use by CMAP staff |
I have been digging into this a bit this afternoon - I concur with @sarahcmap that everything except SVGs appears to be working properly. Specifically, while SVGs are exporting text as text, the bolding is not consistent with other exports - this is particularly noticeable for the title but it is also relevant for other text on the graph. Also, when you copy and paste that exported text, the font sizes and names are off in a software like Word. I haven't been able to get access to Illustrator today, so I'm not sure what the situation is there. I haven't solved it, but I believe that I've identified part of the problem. The code underlying the SVGs appears to be doing two possibly related things that are causing issues:
I exported the test fonts (using When I modified it to adjust the weighting, I got this (also pushed to this branch as |
Just a note with the proper weights of the different Whitney variants:
|
More generally, it appears that the fonts are not registering as "semibold" or "book" in |
Bear in mind that, as of version 1.2, cmapplot does not use the fonts in |
The only addendum that I would make to this is that register_fonts actually does requires the identification of a "bold" face, so each of our three fonts has been assigned a bold weight. Whitney Semibold calls Whitney Black as bold, Medium calls Bold, and Book calls Semibold. It would be an interesting to know how
This is one of the reasons I find Daniel's svglite outputs so intriguing--they certainly appear to reference "Whitney" as opposed to any specific face, which strikes me as the primary challenge to overcome. |
Yes, it's really bizarre. I wonder if it would produce the same output on a system that doesn't have Whitney already installed. |
This issue is meant to combine the related issues #91, #116, and #120, which I will close after posting this. There may be more useful details in each of those discussions, but I've done my best to capture the most useful links and findings below.
The situation:
svg()
does not export text (it converts text to shapes) and has not proven readable by Illustratorsystemfonts
,ragg
, andsvglite
make cross-platform, consistent graphics rendering with custom fonts possibleragg:agg_png()
(and thereforesystemfonts
) within thepkgdown
package.cmapplot_globals
to a named list rather than an environment, although storing these sorts of variables in an environment seems to be the better practice. We may be able to return the environment structure with the new fonts construction (which may enable an easy fix to constant modifier function #117).Definite projects for v1.2: (followed by possibly useful resources)
finalize_plot()
to use ragg-based raster functions (@sarahcmap) -> in progress in branch v1.2finalizefinalize_plot()
to usesvglite()
instead ofsvg()
(@sarahcmap) -> in progress in branch v1.2finalizeagg
as their RStudioGD backend, and/or manually set this for them (@nmpeterson)Possible projects:
svg()
in addition tosvglite()
-- (need to see how this meshes with systemfonts)cmapplot_globals
in an environment, rather than a named listOther resources (which may be out of date now that systemfonts and ragg exist):
The text was updated successfully, but these errors were encountered: