Unordered list bullet + literal = wrong vertical bullet alignment

[habamax]

tested in beta2 and current master

= test

== test 1
* hello
** world
** `world`
** world `world`
** w``orld``
* hello
* `hello`
* hello

With everything default outputs pdf:

Note if list item starts with inline literal the bullet is misaligned.

PS, boxes and arrows are added afterwards to illustrate the issue.

[habamax]

As a workaround one can add {zwsp} :

[mojavelinux]

I think what's happening is that Prawn is determining the line height based on the first character in the line. If the fonts have different metrics, it ends up using the wrong line height.

I would imagine the same thing would happen if the first character of a paragraph is a monospaced character.

[habamax]

if literal would have content property which is included before the text... It would be possible to add {zwsp} there to fix this. Although it looks dirty :)

[mojavelinux]

That would seem dirty, though it would still be possible to remove the character before inking it. But there may be other solutions to explore as well.

[RarrugasTetra]

The same problem appears when you insert inline formulae (using stem:[]) in list items.

[mojavelinux]

This turns out to affect a lot of elements, including toc entries. Prawn computes the height based on the text you give it. If you only give it monospaced text, then the line height will be different. This can be fixed by the suggestion @habamax came up with, which turns out to be natively supported in Prawn anyway.

The one thing we can't fix is when you have a paragraph and one of the lines in the paragraph is entirely monospaced text. But that's quite an edge case. I think if we focus on the problem at hand, we can cover > 90% of the cases I'd estimate.

It still would be nice if Prawn supported some sort of reference line height that you could pass in. That way, it would use a precomputed value instead of deriving it from the text.

[mojavelinux]

The one thing we can't fix is when you have a paragraph and one of the lines in the paragraph is entirely monospaced text.

I have figured out a solution for this problem.