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