I think something like that is doable and probably worth the extra code complexity if its well designed, but we'd need to work out a spec. I doubt it needs a whole MEP, but can you sketch out more fullsomely the API you'd like to see?

After that, if you wanted to take a try at implimenting it, folks here could help.

@jklymak : here is a first attempt to work out the spec

Basically, the user would be able to specify linewidth/markersize/markeredgewidth property values as either a float (in points) or a text string. In the latter case, the user can either specify:

• a qualitative size (e.g. 'x-small', 'large', 'thin', 'medium', 'xx-thick') relative to a base value, and with a configurable scaling factor (i.e. the value would be computed as base value * base scale**exp, where exp ranges from -3 for 'xx-small' to +3 for 'xx-large')
• a quantitative size that follows the format [num][unit], where num is a float and unit is one of ['pt', 'mm', 'in'] for absolute sizes, or one of ['x', '%'] for sizes relative to a base value.

Examples:

obj.set_linewidth(2.) # set width in points
obj.set_linewdith('3.5 pt') # set width in points
obj.set_linewidth('1 mm') # set width in mm
obj.set_linewidth('0.01 in') # set width in inch
obj.set_linewidth('20%') # set width to 20% of base value
obj.set_linewidth('0.2x') # set width to 0.2 * base value
obj.set_linewidth('x-thick') # set width to base value * base scale**exp['x-thick']
obj.set_markersize('x-small') # for sizes use small/large, for widths use thin/thick

For each property two new rcParams would be needed, e.g. for linewidth

• base.linewidth: only accepts absolute widths (i.e. points, mm or inch)
• base.linewidth_scale: a float

Here is a gist of what a parser of these width/size values could look like, as well as the possible changes needed to set/get_linewidth methods.

Looking forward to your feedback and suggestions.

I would also put the is None check into parse_linewidth.

If we do this for set_linewidth we should also apply it to all artists that have a linewidth.

My biggest concern with this is that the scope will quickly balloon. If we can specify the linewidth as '1 in', then for consistency people will expect to be able to specify other sizes that way as well. Off the top of my head I think 'fontsize' (which already does the relative sizes), marker size and markeredgewidth would also need this. Are there others I am missing? May be fig.set_size_inches?

Why not just use the current linewith rcParams as the base? I am not sure that we also need a scale rcparam (do we have one of those for the relative text scaling?).

The artists with a set_linewidth method are Line2D, Patch and Collection, and Line2D is the only artist with set_markeredgewidth and set_markersize methods. Ticks.set_ticksize would be another one to consider and so is FontProperties.set_size (to be consistent, like you said). So, yes, all these methods would see (minor) changes without altering their default behavior (I think).

I suppose it is possible to use lines.linewidth rcParams as the base width, instead of creating a new rcParams entry. From what I understand, this is basically how it is done for text font size. There would be a slight inconsistency in that lines.linewidth can only take absolute width values, whereas other line width rcParams can be set to either absolute or relative widths.

The scale parameter just provides extra flexibility, but it may not be needed if we can find a good fixed scale that works well. For font sizes the scale is fixed to 1.2

I think being able to specify absolute units ('in', 'cm', 'em' etc) is a wishlist item that shouldn't hold back this idea. See #9226

For now I think

1. qualitative sizes would be good, though lets come up with a good set. (xx-thin, x-thin, thin, medium, thick, x-thick, xx-thick)?
2. Fractional size, delineated by the number being a string instead of a float:
   linewidth=0.5 is in points, linewidth='0.5' if fractional. Note that this parallelels the specification of grays for colors.

If there is a separate linewidth_parser defined somewhere that converts to a floating point number in points, I think the intrusion is minimal and the ability to add other units in future would be easy.

@jklymak
Ok, I'll focus on relative line widths and marker sizes for this issue. Based on your comments, I created a PR that implements support for qualitative line widths, marker edge widths and marker sizes.

Initially, I added fractional sizes (represented as string) as well, but I ran into problems when running the tests. It turns out that when rcParams are loaded from style files through rc_params_from_file, values are passed to the rcParam validator as a string, and would thus always be interpreted as a fractional size string. The original idea of using e.g. '0.5x' for fractional sizes would get around this.

Let me know if the PR is going in the right direction.

One issue that needs to be taken care of is (as always with styling proposals) when does the relative size actually get converted to an actual size? i.e. if I later change the base size, is that supposed to modify what gets drawn?

@anntzer
In the current implementation in the PR, the conversion takes place as soon as the value is set (i.e. internally, the width/size is always in points). This is how it is already implemented for font sizes, if I am not mistaken.

I think that's reasonable. While I'm sure it happens that users change the rcParam in their code, I think its reasonable to not expect it to retroactively change a line width.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!