Manuel Mall wrote:

What about using the UnresolvedElements? Just as per the block-level
space resolution, each inlineLM could append at the beginning and at
the end of its element list an UnresolvedElement storing its border,
padding and spacing information.


I don't know anything about the UnresolvedElements as I so far have not studied the block level LMs. But this reminds about another requirement we may need to consider: Proper conditional start/end space resolution. This is currently not done. I don't think we even have testcases for it. When Jeremias did the block level before/after stuff the idea was that may be we can port this to the inline LMs for the start/end space resolution.

So, we could start from here, using UnresolvedElements to handle inline space resolution, then take into account conditional borders and paddings, and finally trailing / leading space characters.

In the end, it all boils down to compute how much space we have to allocate between two words if there isn't a break, and how much after one and before the other if there is. Sounds almost easy in these words .... there must be a trick somewhere! :-)

[white space handling within markers]

Maybe in this case we could use UnresolvedElements for the "inner"
spaces too (the spaces in the middle of a node text, whose handling
in the previous situation did not need other infrmation).

Not sure here - I am more inclined to reuse the fo logic, that is iterate over all characters in a paragraph and tell the LMs which one to delete probably combined with the Unicode UAX#14 linebreaking.

Ok, effectively if all we have to decide is whether to discard or retain a space character it's better to reuse what we already have.

Regards
    Luca

Reply via email to