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

Parcoords fonts #1624

Merged
merged 6 commits into from
May 9, 2017
Merged

Parcoords fonts #1624

merged 6 commits into from
May 9, 2017

Conversation

monfera
Copy link
Contributor

@monfera monfera commented Apr 26, 2017

Support for specifying fonts for parcoords dimensions. Example, see JS code 8..12:http://codepen.io/anon/pen/QvdwpX

image

@monfera monfera self-assigned this Apr 26, 2017
@@ -81,6 +81,10 @@ function dimensionsDefaults(traceIn, traceOut) {
return dimensionsOut;
}

function coerceFont(fontAttr, coerce, layoutFont, defaultFont) {
var fontSpec = Lib.coerceFont(coerce, fontAttr);
Lib.coerceFont(coerce, fontAttr, Lib.extendFlat({}, layoutFont, defaultFont, fontSpec));
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do you need to call Lib.coerceFont twice?


var extendDeep = require('../../lib/extend').extendDeep;
var extendFlat = require('../../lib/extend').extendFlat;


Copy link
Contributor

Choose a reason for hiding this comment

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

🔪

Copy link
Contributor

Choose a reason for hiding this comment

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

... as we're (slowly) trying to make our code look more like the standard style - which disallows multiple blank lines.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah got it, thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Btw HUGE fan of standard style

Copy link
Contributor

@rreusser rreusser Apr 26, 2017

Choose a reason for hiding this comment

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

Now that there aren't giant outstanding PRs, might be time to revisit: #1371 (though I'm increasingly intrigued by prettier which is fundamentally different from a linter)

Copy link
Contributor

@rreusser rreusser Apr 26, 2017

Choose a reason for hiding this comment

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

--> The selling point of prettier is that you don't have to adhere to any style at all because it doesn't present you with errors. It just makes things consistent. 😄

Copy link
Contributor

Choose a reason for hiding this comment

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

True. But you have to do some non-trivial src vs build file trickery.

Copy link
Contributor

Choose a reason for hiding this comment

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

... adding pre-commit hooks is hardly simplifying anything IMHO.

Copy link
Contributor

@rreusser rreusser Apr 26, 2017

Choose a reason for hiding this comment

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

See #1629 for quick experiment. It replaces lint and lint-fix with prettier equivalents and adds a precommit hook that formats staged files without ever having to manually add a precommit hook.

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 we're bikeshedding #950 (comment)

@@ -47,6 +49,10 @@ module.exports = {
}
},

labelfont: extendFlat({}, fontAttrs, {dflt: {size: 10}, description: 'Sets the font for the `dimension` labels.'}),
Copy link
Contributor

Choose a reason for hiding this comment

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

This is not our usual pattern.

The default font size is inherited from fullLayout.font.size directly as here or times a scalar like here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The purpose was to have smaller fonts than what would come from the layout defaults, which would result in overly big numbers, looked really bad. The dimension labels and tick numbers need to be quite small by default, e.g. around 10px. It's achieved by parcoords/attributes specifying these sizes. Is there another way of saying, 'take layout font values but don't adopt large fonts unless the user wants it, in which case they specify it on eg. labelfont?

@@ -97,4 +100,8 @@ module.exports = function supplyDefaults(traceIn, traceOut, defaultColor, layout
if(!Array.isArray(dimensions) || !dimensions.length) {
traceOut.visible = false;
}

coerceFont('labelfont', coerce, layout.font, attributes.labelfont.dflt || {});
Copy link
Contributor

Choose a reason for hiding this comment

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

Lib.coerceFont('labelfont', coerce, layout.font);

should be enough, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could do that. The consequence is that the tick and dimension label fonts would be too large:
image

It's even worse if the user specified a larger font centrally, e.g. size 16:
image

Since I can go either way, pls confirm if I should preserve the current fontsize-moderation logic or use the simpler logic. Consistency matters a lot on one hand, and having ergonomically good defaults is also valuable.

@@ -227,8 +234,6 @@ function styleExtentTexts(selection) {
selection
.classed('axisExtentText', true)
.attr('text-anchor', 'middle')
.style('font-weight', 100)
.style('font-size', '10px')
Copy link
Contributor

Choose a reason for hiding this comment

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

Ha. I see 10px was used before. I should've caught that. Elsewhere in plotly.js this would be 12px.

I guess we'll have to keep it this way until v2 😬

@etpinard etpinard added this to the 1.27.0 milestone Apr 26, 2017
@@ -227,8 +234,6 @@ function styleExtentTexts(selection) {
selection
.classed('axisExtentText', true)
.attr('text-anchor', 'middle')
.style('font-weight', 100)
Copy link
Contributor

@etpinard etpinard May 1, 2017

Choose a reason for hiding this comment

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

@monfera is removing that font-weight setting on purpose? Unsurprisingly, it makes the image tests fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As we discussed about font standardization... I assumed, perhaps incorrectly, that we don't want to customize it. I do have a preference for the lower font weight as in the case of parcoords the shape of line distribution is more important than the best readability so it's fine to keep the weight=100 but with configuration, the user can probably control the font anyway.

Copy link
Contributor

Choose a reason for hiding this comment

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

We don't set font-weight anyway in our code - though inputting text as <b>text</b> effectively does that.

This is another thing I wished I would've noticed while reviewing your first parcoords PR. Oh well. I think it's best to drop font-weight and make parcoords look a little more plotly-esque.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Cool, in this case I could guess, if a bit late, how you'd go about it :-)

// scale linearly with global font size
var fontDflt = {
family: layout.font.family,
size: Math.round(layout.font.size * (10 / 12)),
Copy link
Contributor

@etpinard etpinard May 1, 2017

Choose a reason for hiding this comment

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

@monfera this is what I came off with.

As you pointed out, changing the font size default to 12 makes most parcoord graphs look less-than-optimal. We should fix that text-overlapping problem at some point though - similar to how we do it currently in cartesian axes. But that's for another PR. So, the 10px default value remains.

But, to make this a little more plotly-esque, we make the parcoord font size scale linearly with layout.font similar to what's done for axes titlefont.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @etpinard, also for the pointer!

@etpinard
Copy link
Contributor

etpinard commented May 9, 2017

@monfera are you ok with my changes?

@monfera
Copy link
Contributor Author

monfera commented May 9, 2017

@etpinard yes, thank you, I should have indicated this more unambiguously in my reply.

@monfera
Copy link
Contributor Author

monfera commented May 9, 2017

Also, overall, looks good!

@etpinard etpinard merged commit 1ffb102 into master May 9, 2017
@etpinard etpinard deleted the parcoords-fonts branch May 9, 2017 14:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants