MagicSetEditor2
MagicSetEditor2 copied to clipboard
twanvl
Add support for bullet points with proper indentation
Add support for bullet points. As seen on cards like [magic charms] (https://gatherer.wizards.com/Pages/Card/Details.aspx?multiverseid=460137).
Maybe more generally, some kind of table layout?
Proposal:
- Internal syntax
"<li>• </li>Lots of text", this would cause "lots of text" to remain indented as far as the bullet - For text fields, allow the bullet point character to be specified, a toolbar button would insert it, default of
•seems reasonable.
"Lots of text" should either break at a linebreak or have its own tags to support things like entwine. Otherwise looks good.
The idea is that indentation happens only for word wrapped lines, so that card would have text "Choose one —\n<li>• </li>Until end of turn, you gain control of target creature and it gains haste.\n<li>• </li>Sacrifice a creature. Grab the Reins deals damage equal to that creature's power to any target.\nEntwine <sym>2R</sym>"
That looks great then.
And secondary request, would it be possible to apply an indent of X pixels to get a formatting like the War of the Spark planeswalkers within one textbox? Presumably something like <li> </li> could create a similar effect, but one that would be unfavorably affected as font size changes.
Maybe something like <margin:123>text of second ability</margin:123> could work for that.
The margins tag would be great if its not too much extra trouble for you.
The implementation is now done except for the GUI. Templates can insert <li>• </li>.
Current issues:
- no GUI yet
- you can accidentally end up with a cursor inside the bullet point and type there
- the spellchecker sees • as a word and underlines it.
<li></li> isn't resetting with softline breaks like it is with hard line breaks
Image
The text of those cards:
card1:
Choose one —
<li>• </li>When there’s hard breaks it wraps around okay.
Choose one —<soft-line>
<li>• </li>When there’s soft breaks it’s less okay.</soft-line>
card2:
Choose one —<soft-line>
<li>• </li>When there’s soft breaks it’s less okay.<soft-line>
<li>• </li>When there’s more, things go really wrong.</soft-line></soft-line>
The idea is that a soft line break would stay within the same bullet point, so you would have to use hard line breaks to make it work. The resulting mess was not intended, though.
Wizards' modals use soft breaks (comparisons), and so its also what many people have theirs written as currently. Maybe <li> and <li-soft> to keep both? not sure if the typical
<ul>
<li>String1</li>
<li>String2</li>
</ul>
format makes sense for MSE, but that's maybe another way to make that decision template side.
Another thought might be to keep softbreaks in a line unless it matches /<softline>\n(</softline>)?<li>/ ? Then you could get the midline drop if you wanted that but if you're starting a new indent it resets rather than chains.
It looks like modal cards do use normal line breaks, compare these cards. It is just that the MSE template uses way to much space for hard line breaks. A soft line break would have the same height as a wrapped line, and there is a bit more space between the bullet points.
The template might be overdoing the hardline size, but comparing them, plus a card with linewrap also from the same set, the third line with the hard line break is under the modal's and the third line with the line wrap is above the modal's.
You are comparing the distance from the baseline to the upper case R, with the distance to a lower case c. However, it seems that the truth is in between. The line spacing is larger than for a wrapped line, but smaller than a hard line break.
You are comparing the distance from the baseline to the upper case R, with the distance to a lower case c.
Well yea because the first two lines are lined up. If the spacings were the same sizes the lowercase c should be on the same level as the lowercase e on the first card, not a pixel lower than capital R there.
Right, I misunderstood. I think we are saying the same thing.
MSE currently doesn't allow different line heights for <li>. If it did you could specify list item margin top: -3, or to stick with tags, use a <margin> tag (that currently only allows left and right margins)
I am also thinking of changing the syntax to <li><bullet>* </bullet>Text goes here</li>
As the line height properties of text fields are scriptable, I've been able to get this working nicely on the hard break system now, so I believe this issue's good to be closed out.