Again, remember these aren't wordbound blanks or block tags, just
superblanks, like <br/>, or other tags that aren't hard breaks or wordbound.

*तन्मय खन्ना *
*Tanmai Khanna*


On Thu, Aug 27, 2020 at 2:33 PM Tanmai Khanna <khanna.tan...@gmail.com>
wrote:

> Or, if we want to give the user complete control of the blanks between the
> output LUs, i.e. if they want a space or not, we can just flush all the
> blanks in the patterns before any LUs are output (or after). It's
> considerably easier to implement and gives the user complete control over
> the spaces between their output LUs.
>
> *तन्मय खन्ना *
> *Tanmai Khanna*
>
>
> On Thu, Aug 27, 2020 at 2:31 PM Tanmai Khanna <khanna.tan...@gmail.com>
> wrote:
>
>> So what I'll try to do, is after the blanks are collected, lets say X is
>> the number of source LUs in the pattern and Y is the number of output LUs.
>> If X = Y then we can keep them in the same place, if X < Y, then we can
>> keep them in the first X gaps the rest can be spaces or whatever the user
>> denotes. If X > Y, then we can print the first Y blanks and then flush the
>> remaining. After this the <b pos> option will become useless. Does that
>> sound good?
>>
>> *तन्मय खन्ना *
>> *Tanmai Khanna*
>>
>>
>> On Thu, Aug 27, 2020 at 2:28 PM Francis Tyers <fty...@prompsit.com>
>> wrote:
>>
>>> El 2020-08-27 09:54, Kevin Brubeck Unhammer escribió:
>>> > Tanmai Khanna <khanna.tan...@gmail.com>
>>> > čálii:
>>> >
>>> >> Hmm, well then I guess for now the small list of tags that still
>>> exist
>>> >> as
>>> >> blanks have to be printed using the <b pos="1"/> option. I could
>>> >> change it
>>> >> so that it flushes all blanks, or keeps them in their position if
>>> >> possible.
>>> >> The good thing is that these aren't wordbound semantically so them not
>>> >> being in their "correct" position won't cause a lot of issues.
>>> >>
>>> >> This can be discussed: Do we want control over where to print these
>>> >> tags if
>>> >> they exist in the stream (not wordbound tags or block tags), or do we
>>> >> want
>>> >> that they flush out anyway and the user shouldn't worry about the
>>> >> blanks.
>>> >
>>> > I would prefer that the user doesn't have to worry about the blanks (or
>>> > the b pos attribute). I can't imagine a use-case where it would matter
>>> > since we don't actually look at the contents, when we write <b…/> in
>>> > a rule we just want there to be some space between the words.
>>> >
>>> > Ideally the blanks would be printed as close as possible to where they
>>> > were, but if these are rare (and don't belong on words and don't have
>>> > anything to do with structure) maybe it's not so important, as long as
>>> > they get printed before/after the rule output.
>>> >
>>>
>>> Agree, blank handling should not really be handled in transfer, putting
>>> <b/>
>>> is ok, but we shouldn't be controlling it with the pos="" option.
>>>
>>> Fran
>>>
>>>
>>> _______________________________________________
>>> Apertium-stuff mailing list
>>> Apertium-stuff@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/apertium-stuff
>>>
>>
_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff

Reply via email to