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

Fall back to local glyph rendering if glyph PBF is unavailable #4564

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

1ec5
Copy link
Contributor

@1ec5 1ec5 commented Aug 15, 2024

If a glyph PBF is unavailable, try to fall back to local glyph rendering, and keep rendering the map without crashing.

A label “ABC” followed by the Object Replacement Character followed by “ABC” against a gray background.

Fixes #3302 and fixes #4563.

Launch Checklist

  • Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
  • Briefly describe the changes in this PR.
  • Link to related issues.
  • Include before/after visuals or gifs if this PR includes visual changes.
  • Write tests for all new functionality.
  • Document any changes to public APIs.
  • Post benchmark scores.
  • Add an entry to CHANGELOG.md under the ## main section.

@codecov-commenter
Copy link

codecov-commenter commented Aug 15, 2024

Codecov Report

Attention: Patch coverage is 85.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 87.97%. Comparing base (42d6847) to head (a56d0f8).
Report is 92 commits behind head on main.

Files with missing lines Patch % Lines
src/render/glyph_manager.ts 85.00% 2 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4564      +/-   ##
==========================================
+ Coverage   87.74%   87.97%   +0.22%     
==========================================
  Files         247      247              
  Lines       33494    33510      +16     
  Branches     2414     2375      -39     
==========================================
+ Hits        29390    29481      +91     
+ Misses       3118     3058      -60     
+ Partials      986      971      -15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@1ec5 1ec5 force-pushed the glyph-missing-warn-4563 branch from 96f830f to 8d37a1a Compare August 15, 2024 23:32
@@ -108,7 +109,22 @@ export class GlyphManager {
entry.requests[range] = promise;
}

const response = await entry.requests[range];
let response;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this block to a different method maybe? This method is already too long I think

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, looking at the code above this part, can we now handle the case where url is not defined? I know it's not optimal, but there are situations where you just want the text to be render without finding a glyph server. You'd need to define localIdeographFontFamily anyway, which doesn't have a default, so you'd need to know what you are doing...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ultimately, I would love to make glyph PBFs completely optional. However, the style specification currently states that glyphs is required as long as any layer has a text-field property. Would relaxing that requirement constitute a breaking change in either the style spec or GL JS?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it will be a breaking change as changing a required field to optional doesn't sound like a breaking change (unless you have invalid styles, which I'm not sure are interesting).
Relaxing it would make a far better developer experience, IMHO, as I find these glyphs requirement non-friendly...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this should be brought in the style spec repo first...

@HarelM
Copy link
Collaborator

HarelM commented Aug 18, 2024

Looks good, thanks!

@@ -129,13 +145,13 @@ export class GlyphManager {
/\p{Ideo}|\p{sc=Hang}|\p{sc=Hira}|\p{sc=Kana}/u.test(String.fromCodePoint(id));
}

_tinySDF(entry: Entry, stack: string, id: number): StyleGlyph {
_tinySDF(entry: Entry, stack: string, id: number, force: boolean): StyleGlyph {
const fontFamily = this.localIdeographFontFamily;
Copy link
Contributor Author

@1ec5 1ec5 Aug 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m wary of choosing a font for non-ideographic text based on an option called localIdeographFontFamily. The choice should be up to the style author, in the stylesheet, and it should vary from layer to layer, just as in CSS. The iOS implementation has long attempted to match the text-font property to a local or system font. I think GL JS should attempt some matching along these lines.

Unfortunately, many non-Mapbox-hosted fontstacks are named according to the styles for which they were created, obscuring the PostScript names of the fonts from which they were derived. For example, OpenHistoricalMap has “OpenHistorical Bold”, and OSM Americana has “Americana-Bold”. These fontstacks are a pastiche of various fonts from different families. The style authors can’t simply append Open Sans, Unifont, or Noto Sans to the array, because text-font isn’t a fallback list. It simply joins the array into a comma-separated list and includes it in the request URL, so the request would fail and we’d be right back to where we started.

In order to typeset these layers in the designer’s choice of fonts, we could interpret text-font as a cascading fallback list of local font names or keywords (similar to CSS) if the glyph PBF request fails. We could short-circuit that request if glyphs is absent. Or we could introduce a new layout property, such as text-font-family or text-font-names, to represent a cascading fallback list. In the latter case, text-font would remain for backwards compatibility or where a fontstack is preferred for some reason.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think fallback is better than introducing a new field which would create confusion.
If the style and the server are not aligned, presenting something is better than not presenting anything, IMHO.

@spatialillusions
Copy link

Ping. Any plans for merging this?

@HarelM
Copy link
Collaborator

HarelM commented Nov 10, 2024

I think @1ec5 mentioned there is work that he is planning to do before this can be merged as far as I remember...

@1ec5
Copy link
Contributor Author

1ec5 commented Nov 11, 2024

Yes, the to-do list looks like:

  • Relax the requirement for glyphs
  • Go back to only using localIdeographFontFamily for ideographic ranges
  • Try to match text-font to a local font (pass in the property value to TinySDF as the fontFamily)

These changes are straightforward but may require a proposal to change the style spec. I haven’t gotten around to that part yet.

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