Add support for numeric font `weight`#6990

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

emilykl · 2024-05-06T13:53:45Z

@archmoj Is this adding a new functionality to coerce, where numeric (or other) properties can also be configured to accept a list of 'extra' values?
That's pretty cool -- is there anywhere we should document that internally?

Good question.
Yes that's true.
We have other types that support the extras option so I think it's clear internally.
But on plotly.py we need to see if this changes would be reflected properly by codegen.

Good point.
Makes me think, it would be awesome if we could build checking the Plotly.py codegen into the CI process. It would have to produce some kind of output that's easy to verify. It could run only if the schema.json has changed.

Perhaps add a line in the docstring here explaining extras for integers (like the explanation here for flaglist)

For flag lists combination mean something. That's why it is commented.

emilykl · 2024-05-08T21:11:46Z

Why is this needed if we are already disallowing numeric weight values at the schema level?

Good question.
This is for scattergl with limited support of weight noting that for arrayOk attributes we do not check every element at the supply defaults step which could result in performance issues during interactions with the plot.
As a result this fall back is needed to map unsupported values in arrays to supported options.

gotcha, thank you. Could you perhaps add that as a comment above the function definition?

Addressed in 48d057f.

emilykl · 2024-05-08T21:25:25Z

Shouldn't the threshold be 400?

500 is Medium looks very similar to Regular.
IMHO it's debatable between 450/500 to 550.

Right, ok, I guess if the only options are normal or bold we have to draw the line somewhere. Maybe just add a comment explaining why 500 is chosen as the threshold.

emilykl · 2024-05-08T18:54:34Z

@archmoj Does Mapbox make their list of supported fonts public anywhere as part of their package? Just wondering if there's a way we can ensure this list is always up-to-date without updating it manually.

No in fact we use latest v1 version of mapbox-gl. Due to the licence changes of their v2+ no significant v1 is expected. On the other hand we may switch to maplibre-gl-js which is the continuation of mapb0x-gl v1. See #5578.
BTW we could possibly improve our docs for these fonts in a separate PR.

OK got it. Do you know to what extent maplibre supports different font weights? Basically, will adding these options make switching to maplibre significantly more complicated?

I don't think so. It's a kind of problem we could address when/if we switch to it.

@emilykl , there is a migration branch in here maplibre where we should be able to try out:
Migrate to MapLibre #7015

emilykl · 2024-05-08T21:23:52Z

nit: Couldn't this be family.startsWith('Open Sans') ?

Sure. That may break IE11 which is fine as of today :)

emilykl · 2024-05-08T20:09:31Z

Doesn't this else mean the font will default to Klokantech Noto Sans if it's not Metropolis or Open Sans?

oh I see, maybe not, because it has already passed through the supplyDefaults step -- can you confirm @archmoj ?

Good point. No that shouldn't happen because further down we test and ensure the font is supported.
I could restrict this else to make it read better?

Addressed in bff00ac.

emilykl · 2024-05-08T20:14:47Z

ok, naive question because I don't quite understand -- if the user passes just Metropolis (for example) as the font family, won't that register as "not supported" because the string Metropolis is not in the supported fonts list, and so it will get replaced with Open Sans?

Now that we have weight and style options, would it make sense to change that behavior? Since a user could pass family: 'Metropolis', weight: 'bold' and we could use that to determine they want the font face Metropolis Bold.

Actually I was thinking about that and I'd be happy to work on it in a separate PR.
Obviously we don't want to break previous mocks.
Instead we could work on "adding support for minimal family names in mapbox".

ok, that's fine to do in another PR. Would be nice to have!

Tracked in #6993.

Original file line number	Diff line number	Diff line change
		@@ -0,0 +1 @@
		- Add support for numeric text font `weight` [[#6990](https://github.com/plotly/plotly.js/pull/6990)]

-Original file line number
+Diff line change
@@ Expand Up / @@ -100,6 +100,8 @@ exports.valObjectMeta = { @@
  requiredOpts: [],
  otherOpts: ['dflt', 'min', 'max', 'arrayOk'],
  coerceFunction: function(v, propOut, dflt, opts) {
+ if(isTypedArraySpec(v)) v = decodeTypedArraySpec(v);
  if(!isNumeric(v) ||
  (opts.min !== undefined && v < opts.min) ||
  (opts.max !== undefined && v > opts.max)) {
@@ Expand All / @@ -114,8 +116,15 @@ exports.valObjectMeta = { @@
  'are coerced to the `dflt`.'
  ].join(' '),
  requiredOpts: [],
- otherOpts: ['dflt', 'min', 'max', 'arrayOk'],
+ otherOpts: ['dflt', 'min', 'max', 'arrayOk', 'extras'],
  coerceFunction: function(v, propOut, dflt, opts) {
+ if((opts.extras || []).indexOf(v) !== -1) {
+ propOut.set(v);
+ return;
+ }
+ if(isTypedArraySpec(v)) v = decodeTypedArraySpec(v);
  if(v % 1 || !isNumeric(v) ||
  (opts.min !== undefined && v < opts.min) ||
  (opts.max !== undefined && v > opts.max)) {
@@ Expand DownExpand Up / @@ -156,6 +165,8 @@ exports.valObjectMeta = { @@
  requiredOpts: [],
  otherOpts: ['dflt', 'arrayOk'],
  coerceFunction: function(v, propOut, dflt) {
+ if(isTypedArraySpec(v)) v = decodeTypedArraySpec(v);
  if(tinycolor(v).isValid()) propOut.set(v);
  else propOut.set(dflt);
  }
@@ Expand DownExpand Up / @@ -198,6 +209,8 @@ exports.valObjectMeta = { @@
  requiredOpts: [],
  otherOpts: ['dflt', 'arrayOk'],
  coerceFunction: function(v, propOut, dflt) {
+ if(isTypedArraySpec(v)) v = decodeTypedArraySpec(v);
  if(v === 'auto') propOut.set('auto');
  else if(!isNumeric(v)) propOut.set(dflt);
  else propOut.set(modHalf(+v, 360));
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -20,6 +20,27 @@ module.exports = function(opts) { @@
  var editType = opts.editType;
  var colorEditType = opts.colorEditType;
  if(colorEditType === undefined) colorEditType = editType;
+ var weight = {
+ editType: editType,
+ valType: 'integer',
+ min: 1,
+ max: 1000,
+ extras: ['normal', 'bold'],
+ dflt: 'normal',
+ description: [
+ 'Sets the weight (or boldness) of the font.'
+ ].join(' ')
+ };
+ if(opts.noNumericWeightValues) {
+ weight.valType = 'enumerated';
+ weight.values = weight.extras;
+ weight.extras = undefined;
+ weight.min = undefined;
+ weight.max = undefined;
+ }
  var attrs = {
  family: {
  valType: 'string',
@@ Expand DownExpand Up / @@ -49,15 +70,7 @@ module.exports = function(opts) { @@
  editType: colorEditType
  },
- weight: {
- editType: editType,
- valType: 'enumerated',
- values: ['normal', 'bold'],
- dflt: 'normal',
- description: [
- 'Sets the weight (or boldness) of the font.'
- ].join(' ')
- },
+ weight: weight,
  style: {
  editType: editType,
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -107,7 +107,7 @@ module.exports = function toSVG(gd, format, scale) { @@
  // Drop normal font-weight, font-style and font-variant to reduce the size
  var fw = this.style.fontWeight;
- if(fw && fw === 'normal') {
+ if(fw && (fw === 'normal' || fw === '400')) { // font-weight 400 is similar to normal
  txt.style('font-weight', undefined);
  }
  var fs = this.style.fontStyle;
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -41,6 +41,7 @@ var attrs = module.exports = overrideAll({ @@
  editType: 'calc',
  colorEditType: 'style',
  arrayOk: true,
+ noNumericWeightValues: true,
  variantValues: ['normal', 'small-caps'],
  description: 'Sets the text font.'
  }),
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -190,7 +190,7 @@ function convertTextStyle(gd, trace) { @@
  if(
  isArrayOrTypedArray(tfs) ||
  Array.isArray(tff) ||
-Array.isArray(tfw) ||
+isArrayOrTypedArray(tfw) ||
  Array.isArray(tfy) ||
  Array.isArray(tfv)
  ) {
@@ Expand All / @@ -207,7 +207,7 @@ function convertTextStyle(gd, trace) { @@
  ) * plotGlPixelRatio;
  fonti.family = Array.isArray(tff) ? tff[i] : tff;
- fonti.weight = Array.isArray(tfw) ? tfw[i] : tfw;
+ fonti.weight = weightFallBack(isArrayOrTypedArray(tfw) ? tfw[i] : tfw);
  fonti.style = Array.isArray(tfy) ? tfy[i] : tfy;
  fonti.variant = Array.isArray(tfv) ? tfv[i] : tfv;
  }
@@ Expand All / @@ -216,7 +216,7 @@ function convertTextStyle(gd, trace) { @@
  optsOut.font = {
  size: tfs * plotGlPixelRatio,
  family: tff,
- weight: tfw,
+ weight: weightFallBack(tfw),
  style: tfy,
  variant: tfv
  };
@@ Expand All / @@ -225,6 +225,14 @@ function convertTextStyle(gd, trace) { @@
  return optsOut;
 }
+// scattergl rendering pipeline has limited support of numeric weight values
+// Here we map the numbers to be either bold or normal.
+function weightFallBack(w) {
+ if(w <= 1000) {
+ return w > 500 ? 'bold' : 'normal';
+ }
+ return w;
+}
 function convertMarkerStyle(gd, trace) {
  var count = trace._length;
@@ Expand Down @@

-Original file line number
+Diff line change
@@ -0,0 +1,45 @@
+'use strict';
+// Must use one of the following fonts as the family, else default to 'Open Sans Regular'
+// See https://github.com/openmaptiles/fonts/blob/gh-pages/fontstacks.json
+var supportedFonts = [
+ 'Metropolis Black Italic',
+ 'Metropolis Black',
+ 'Metropolis Bold Italic',
+ 'Metropolis Bold',
+ 'Metropolis Extra Bold Italic',
+ 'Metropolis Extra Bold',
+ 'Metropolis Extra Light Italic',
+ 'Metropolis Extra Light',
+ 'Metropolis Light Italic',
+ 'Metropolis Light',
+ 'Metropolis Medium Italic',
+ 'Metropolis Medium',
+ 'Metropolis Regular Italic',
+ 'Metropolis Regular',
+ 'Metropolis Semi Bold Italic',
+ 'Metropolis Semi Bold',
+ 'Metropolis Thin Italic',
+ 'Metropolis Thin',
+ 'Open Sans Bold Italic',
+ 'Open Sans Bold',
+ 'Open Sans Extrabold Italic',
+ 'Open Sans Extrabold',
+ 'Open Sans Italic',
+ 'Open Sans Light Italic',
+ 'Open Sans Light',
+ 'Open Sans Regular',
+ 'Open Sans Semibold Italic',
+ 'Open Sans Semibold',
+ 'Klokantech Noto Sans Bold',
+ 'Klokantech Noto Sans CJK Bold',
+ 'Klokantech Noto Sans CJK Regular',
+ 'Klokantech Noto Sans Italic',
+ 'Klokantech Noto Sans Regular'
+];
+module.exports = {
+ isSupportedFont: function(a) {
+ return supportedFonts.indexOf(a) !== -1;
+ }
+};

-Original file line number
+Diff line change
@@ Expand Up / @@ -10,6 +10,7 @@ var Colorscale = require('../../components/colorscale'); @@
 var Drawing = require('../../components/drawing');
 var makeBubbleSizeFn = require('../scatter/make_bubble_size_func');
 var subTypes = require('../scatter/subtypes');
+var isSupportedFont = require('./constants').isSupportedFont;
 var convertTextOpts = require('../../plots/mapbox/convert_text_opts');
 var appendArrayPointValue = require('../../components/fx/helpers').appendArrayPointValue;
@@ Expand DownExpand Up / @@ -369,11 +370,58 @@ function arrayifyAttribute(values, step) { @@
 function getTextFont(trace) {
  var font = trace.textfont;
- var str = '';
- if(font.weight === 'bold') str += ' Bold';
- if(font.style === 'italic') str += ' Italic';
- var textFont = font.family;
- if(str) textFont = textFont.replace(' Regular', str);
- textFont = textFont.split(', ');
+ var family = font.family;
+ var style = font.style;
+ var weight = font.weight;
+ var parts = family.split(' ');
+ var isItalic = parts[parts.length - 1] === 'Italic';
+ if(isItalic) parts.pop();
+ isItalic = isItalic || style === 'italic';
+ var str = parts.join(' ');
+ if(weight === 'bold' && parts.indexOf('Bold') === -1) {
+ str += ' Bold';
+ } else if(weight <= 1000) { // numeric font-weight
+ // See supportedFonts
+ if(parts[0] === 'Metropolis') {
+ str = 'Metropolis';
+ if(weight > 850) str += ' Black';
+ else if(weight > 750) str += ' Extra Bold';
+ else if(weight > 650) str += ' Bold';
+ else if(weight > 550) str += ' Semi Bold';
+ else if(weight > 450) str += ' Medium';
+ else if(weight > 350) str += ' Regular';
+ else if(weight > 250) str += ' Light';
+ else if(weight > 150) str += ' Extra Light';
+ else str += ' Thin';
+ } else if(parts.slice(0, 2).join(' ') === 'Open Sans') {
+ str = 'Open Sans';
+ if(weight > 750) str += ' Extrabold';
+ else if(weight > 650) str += ' Bold';
+ else if(weight > 550) str += ' Semibold';
+ else if(weight > 350) str += ' Regular';
+ else str += ' Light';
+ } else if(parts.slice(0, 3).join(' ') === 'Klokantech Noto Sans') {
+ str = 'Klokantech Noto Sans';
+ if(parts[3] === 'CJK') str += ' CJK';
+ str += (weight > 500) ? ' Bold' : ' Regular';
+ }
+ }
+ if(isItalic) str += ' Italic';
+ if(str === 'Open Sans Regular Italic') str = 'Open Sans Italic';
+ else if(str === 'Open Sans Regular Bold') str = 'Open Sans Bold';
+ else if(str === 'Open Sans Regular Bold Italic') str = 'Open Sans Bold Italic';
+ else if(str === 'Klokantech Noto Sans Regular Italic') str = 'Klokantech Noto Sans Italic';
+ // Ensure the result is a supported font
+ if(!isSupportedFont(str)) {
+ str = family;
+ }
+ var textFont = str.split(', ');
  return textFont;
 }

Uh oh!

Uh oh!

Add support for numeric font weight#6990

Uh oh!

Add support for numeric font weight#6990

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

emilyklMay 8, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Add support for numeric font weight#6990

Uh oh!

Add support for numeric font `weight`#6990

Add support for numeric font `weight`#6990

emilyklMay 8, 2024•
edited
Loading

Add support for numeric font `weight`#6990

Add support for numeric font `weight`#6990

emilyklMay 8, 2024•
edited
Loading