Breaking Font Changes in 4.25

710
4
Jump to solution
03-23-2023 12:29 PM
JoelBennett
MVP Regular Contributor

Starting in 4.25, the underlying logic of symbolUtils.renderPreviewHTML started using fonts from a repository in woff2 format in order to do its work for TextSymbols. If you are using a font repository other than the default (i.e. by setting esriConfig.fontsURL), you will find this suddenly not working. There was no discussion of this in the release notes. The Labeling page also continues to say that support for applicable TextSymbol properties are based on hosted files in .pbf format. The aforementioned esriConfig.fontsURL documentation also speaks solely of files in .pbf format.

All of the fonts in the default repository are also hosted in woff2 format, except for the following exceptions: Arial, Arial Unicode MS, and Palatino Linotype. That is, the following .woff2 URLs return a 404:

However, their corresponding .pbf URLs work just fine:

 

Will the missing fonts be added, and will the documentation be updated?  Is it really necessary that we must have the same fonts in two different formats?

0 Kudos
1 Solution

Accepted Solutions
BjornSvensson
Esri Regular Contributor

Hi @JoelBennett 
Thanks for pointing this out. We will update the documentation.

For now, we're not planning to add those seven woff2; and yes, the fonts needs to be available for full functionality. The PBF is used by TextSymbol and labelling, while WOFF2 is used by Legend/renderPreviewHTML.

On a side note, I'm curious about (1) what your specific use case is for using esriConfig.fontsURL and (2) if your concern is about the console log / 404 request for the non-existing files or something else?

View solution in original post

4 Replies
BjornSvensson
Esri Regular Contributor

Hi @JoelBennett 
Thanks for pointing this out. We will update the documentation.

For now, we're not planning to add those seven woff2; and yes, the fonts needs to be available for full functionality. The PBF is used by TextSymbol and labelling, while WOFF2 is used by Legend/renderPreviewHTML.

On a side note, I'm curious about (1) what your specific use case is for using esriConfig.fontsURL and (2) if your concern is about the console log / 404 request for the non-existing files or something else?

JoelBennett
MVP Regular Contributor

Aloha @BjornSvensson -

Thank you for your reply.  To answer your first question, I suppose my reply is twofold.  The first part is that our platform runs on 3 networks, 2 of which are restrictive and do not have internet access.  Therefore, it is required to host the API and fonts locally.  The second part is that for the 3rd network with internet access, we need to eliminate unnecessary 3rd party services wherever possible.  This is because if the cord to the outside world (i.e. internet) gets cut, our applications should still be able to continue to run as much as possible.  Therefore, this includes hosting the API and fonts on those internal servers as well.

For your second question, I suppose that's twofold as well.  To me, 404 errors (and errors in general) are something that need to be fixed...but that's just me.  I suppose the bigger concern is that the application is supposed to be rendering the previews in a particular way, but in these cases it doesn't, so it comes down to us offering our clients something that isn't performing as advertised.  Granted, this particular case borders on the trivial, but it's still something I have to work through.

If you don't mind my asking, is there any reasoning you can share about those other 7 fonts not being added?  Those Arial ones are probably the most widely recognized amongst the group and would be useful.

BjornSvensson
Esri Regular Contributor

If you don't mind my asking, is there any reasoning you can share about those other 7 fonts not being added?  Those Arial ones are probably the most widely recognized amongst the group and would be useful.

Legal unclarity, not technical. I'll try to follow up with our legal department.  

0 Kudos
JoelBennett
MVP Regular Contributor

Thank you @BjornSvensson  for the changes to the labeling documentation in 4.27; they speak well to the topics discussed further above.

Only one issue I've noticed: in the "Non-MapImageLayer fonts" section of the Labeling page, it indicates the only font not supported in woff2 format is Palatino Linotype Regular, but I've noticed the first 4 fonts starting with "Arial" aren't supported either:

Arial Bold
Arial Bold Italic
Arial Italic
Arial Regular

Will these Arial fonts be added to the repository, or should they be added to the list of exceptions in the documentation?

0 Kudos