Transform LineWidth to TikZ equivalent

[PeterPablo]

Currently getLineOptions() ignores the width of a line as long as strict mode is not enabled. Wouldn't it make sense to match the linewidths to the ones known by PGFplots / TikZ, e.g ultrathin, thick, etc.? Literature:

• pgfplots.pdf -> 4.7.4 Font Size and Line Width
• pgfmanual.pdf -> 15.3.1 Graphic Parameters: Line Width, Line Cap, and Line Join

[egeerardyn]

We do have support for line widths, even in that function:

matlabDefaultLineWidth = 0.5;
   if m2t.cmdOpts.Results.strict ...
           || ~abs(lineWidth-matlabDefaultLineWidth) <= m2t.tol
       lineOpts{end+1} = sprintf('line width=%.1fpt', lineWidth);
   end

That means: if it's in strict mode, always explicitly specify it. If it is not, only include it if it deviates from the default. We should probably use the "factory"-powered functions instead.

However, TikZ supports explicit line widths. Using the semantic versions is nice if you are writing code by hand, but in this case I would strongly advise against it. Because we would need a mapping between semantic (e.g. thick) and absolute schemes (e.g. 3pt). I consider such a mapping brittle since we have to mimic the behavior of TikZ/pgfplots, both of which can change their mapping at any time. Mapping between MATLAB and TikZ absolute units is not always straightforward, so please let's not stray into semantic-absolute conversions: they are very likely to be wrong in at least a lot of cases.

edit: I will leave this bug open as a reminder to use the factory methods, i.e. #377 and possibly #441.

[PeterPablo]

Obviously I had a look at the code and know that currently line widths are transferred with explicit widths of unit points. The mapping to semantic names is straight forward according to the TikZ manual (see above). Of course the definitions theoretically could change in the future, though personally I do not think this is likely to happen (why should it?).

I see a benefit: A user could locally/globally redefine the meaning of /tikz/thick to his personal liking (e.g. 4.3pt) and by doing that modify all plots that make us of that definition.

@egeerardyn I understand your opinion on problematic conversions (--> marker sizes), but in this specific case it appeals as a precise definition to me (the same as with translateLineStyle()).

[egeerardyn]

@PeterPablo I agree that it is quite unlikely to change, but it remains undesirably in my opinion because of this semantic-absolute mapping.

The problem with is: e.g. if normal is 1pt and thick is 3pt, what should we do with a line of width 2.75pt? There are a few options:

1. convert it to the nearest semantical equivalent,
2. leave it in absolute values,
3. define our own style definition (or even go further and implement #262),
4. leave it as-is.

Option 1 needlessly reduces the accuracy that one is able to attain to represent line widths. Option 2 makes that in your use-case some lines will re-scale, others will not. That is just weird behavior. Option 3 could be feasible, but in such a case I think it is more desirable to have decent style support as I once suggested in #262. That solves your use-case as well. Option 4 has the disadvantage that is not semantical, so not idiomatic TeX code (with all consequences).

I also completely understand why you want to have this kind of feature and for my personal workflow it would be convenient to have much further support for these kinds of things, but I don't think that such feature is a good fit for most of our users, so that's why I'd suggest leaving everything as-is. However, if you really want this, I personally have no objections against having such a feature available as an option: e.g. a default mode, a strict mode and a semantic mode.

[PeterPablo]

Thank you for elaborating your thoughts. My instinct would have suggested Option 2. You are correct that such a behavior might (!) irritate users. I'd personally prefer to not have an additional mode in m2t, since that would add another layer of complexity for testing that could be avoided by a different design decision.

This is nothing I really badly need now and I anticipated divergent opinions. That's the reason for discussing it first and not "blindly" creating a PR that could end up being rejected.

262 would indeed be nice, though would not really cover this specific wish/issue since the style would contain something like ..., line width=3pt, ... which still is not semantic.

[egeerardyn]

@PeterPablo I don't know the likelihood of the behavior Option 2 irritating people, but I don't want to underestimate that. We though the same about the sizes of markers: that should be straightforward, but it isn't. If I remember correctly, there the output is quite different for 6pt and 6.1pt. By offering both semantic and absolute measures, we would be doing something identical (or rather similar, since I still do not fully understand marker sizing in MATLAB).

Having an additional "semantic" mode is indeed a big disadvantage for testability.

262 is indeed not entirely about semantics at the same level, but extracting the style definition to a more convenient location, which can be used to get semantic abstraction at a different level.

That's also how I view LaTeX works: in your document (top level) you deal with semantics and you define how such semantics should look somewhere else (e.g. package, document class, pre-amble, ...). But since #262 would ease my personal workflow, I acknowledge that my opinion in this regard might be subject to an extreme bias.

[egeerardyn]

@matlab2tikz/developers Could somebody weigh in on translating line widths (e.g. 3pt) to their TikZ semantical counterparts (e.g. thick, ultrathin, ...)? Personally, I'd leave this implementation as-is since I think we can get more wrong with such a mapping than we can add in value. If there is no demand for this feature, maybe we should close this issue?

[okomarov]

I once tried to make sense of the marker 'business' after nidrosian's initial big effort. Two days of work later, I found to my disappointment that they do not grow linearly and that my adjustments would work only for the test size.

This feature request has all the potential to be a second marker size issue and hence I am personally for closing it :sweat_smile:

[PeterPablo]

Let's close this -- we can revive this, as soon as we run out of work :sweat_smile: