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
