Den 05. april 2016 01:55, skrev LyX Ticket Tracker:
Comment (by uwestoehr):

  > As I understand it, due to the creative data handling used for \width
  and friends, the screen shows 1 inch in any case. Or something else, I am
  not really sure.

  The real bug is that LyX offered this unit for the width of boxes this
  doesn't make sense because 1\width sets the width of the box as width, see
  sec. 5.2.1 of the EmbeddedObjects manual.
  LaTeX does nevertheless allow this unit and for backward compatibility, we
  must keep it.
The way I see it, this width makes a lot of sense. It specifies that the box does NOT have a fixed width – instead, it takes the width of whatever I put inside.

This means the box can be used to put a frame around something that has unknown width. Such as a table whose width comes from the longest strings inside. Or some image. (Image may change size later, when the draft is replaced by a finished more detailed image) Or some text - where the width cannot be determined in advance because I will change the document font later on.

  For new boxes you cannot set 1\width for the width, only for the height.
  (One still can get this for simple boxes (\mbox of \fbox) for the
  mentioned backward compatibility.).
I know that this setting is only available for some boxes (simple frame, no inner box). I always believed that was a limitation of LaTeX. The way I see it, it is not some "backward compatibility" thing, but a very useful
function.

Sometimes I don't want a fixed-size box. I want a box "around" something. The box is a markup, much like "bold". It doesn't change formatting (except by using a little space), it makes something prettier or makes it stand out. In my specific case, the box goes around a table so it looks like a double line around the table.


  So before we fiddle around with a quite strange feature that is illogic
  for average users, I propose to do nothing.
If it inconsistent that this size isn't a percentage, feel free to clean up the LyX user interface. "100% of internal width" is fine, as long as the same LaTeX is emitted as when I have 1\width today. Having LyX being more consistent than LaTeX is probably a good thing, just don't loose the functionality.

I also understand that the developers may have more important tasks to worry about. But I would hope the decision would be "postpone until someone feel like working on this" rather than "won't fix". I may be able to look at this myself during summer, but I hope the feature is not being phased out!
  Please use a sensible width unit for your box and it should work. here it
  works correct, if you use the 100 text% and this is what you want, right?
No, I do not want 100% of text width. That gives me a box that goes from margin to margin, regardless of what size the table gets. (The table size varies, depending on the longest strings inside. Which varies
depending on what names I need to write in certain fields.)

What I want here, is a box that wraps the table to give the impression of a double-walled table. A table setting might be a more logical way; but to my knowledge, LyX does not support that. So wrapping the table in a tight-fitting box is the way to go currently. It makes some sense - boxes "for decoration" is common. But even if the "table case" gets solved by support for some sort of "pretty table package", there is still the case of wrapping an image in a box, highlighting a word with a tight-fitting box, or a box around a TikZ animation.
  > Another related weirdness is that one sets "1 Width", but "100 Textwidth
  %".

  Because \width is no percentage unit and a special one only for simple
  boxes.
Well, the LyX interface can be cleaned up so the user see "100% of content width". This can be done without changing the LaTeX emitted, and without changing the file format too. That is a dialog presentation issue.

However, as long as LyX has the ability to "wrap content in a content-sized box", then it'd be nice if the box was content-sized on screen too – instead of constant-sized.

The content render just fine on screen if there is no box around it, so getting the content size ought to be possible. Then the box can be drawn around whatever screen size the content has. A single-cell table (used as markup) already works that way on screen. But single-cell tables aren't that logical either, and have other formatting/alignment issues.

Helge Hafting

Reply via email to