On 8/27/2018 2:20 PM, Rebecca
Bettencourt via Unicode wrote:
> That
sounds like a non-conformant use of characters
> Date: Tue, 28 Aug 2018 13:44:58 +0300
> From: Cosmin Apreutesei via Unicode
>
> There is this sentence in UAX#9 which provides a clue: "[...] trailing
> whitespace will appear at the visual end of the line (in the paragraph
> direction).". I'm not sure what that means, but by doing some tests
Hello everyone,
I'm having a bit of trouble implementing line wrapping with bidi and I
would like to ask for some advice or hints on what is the proper way
to do this.
UAX#9 section 3.4 says that bidi reordering should be done after line
wrapping. But in order to do line wrapping correctly I
Asmus Freytag wrote:
> There are situations where an ad-hoc markup language seems to fulfill a need
> that is not well served by the existing full-fledged markup languages. You
> find them in internet "bulletin boards" or services like GitHub, where pure
> plain text is too restrictive but the
James Kass wrote:
> Non-conformant? Well, it's probably overkill anyway. A simpler method of
> identifying which PUA convention is being used for a file
would be to either have the first line of the file being something like
[PUA1] or to have the file name be something like
Hi
Mark E. Shoulson wrote:
> I'm not sure what the advantage is of using circled characters instead of
> plain old ascii.
My thinking is that "plain old ascii" might be used in the text encoded in the
file. Sometimes a file containing Private Use Area characters is a mix of
regular
Hi Eli, thanks for answering! I think I'm getting closer. Just a few
more clarifications if you please.
> That is not so if the line ends after the whitespace: in that case the
> whitespace is trailing, and will appear at the visual end of the
> line.
So only if it's a soft break I should indeed
Hi Philippe,
> The space encoded just before the logical end of line or linewrap (in the
> middle of the displayed line) has to be moved at end of the physical line (in
> the paragraph direction), it should not be kept in the middle.
Ok, that seem to confirm what Eli is saying and it clarifies
On August 23, 2011, Asmus Freytag wrote:
> On 8/23/2011 7:22 AM, Doug Ewell wrote:
>> Of all applications, a word processor or DTP application would want
>> to know more about the properties of characters than just whether
>> they are RTL. Line breaking, word breaking, and case mapping come to
>>
> From: Cosmin Apreutesei
> Date: Tue, 28 Aug 2018 21:28:58 +0300
> Cc: unicode@unicode.org
>
> > That is not so if the line ends after the whitespace: in that case the
> > whitespace is trailing, and will appear at the visual end of the
> > line.
>
> So only if it's a soft break I should
>
> On 27 August 2018 at 15:22 Peter Constable via Unicode
> wrote:
>
> Layout engines that support CJK vertical layout do not rely on the 'vert'
> feature to rotate glyphs for CJK ideographs, but rather rotate the glyph 90°
> and switch to using vertical glyph metrics. The 'vert'
The space encoded just before the logical end of line or linewrap (in the
middle of the displayed line) has to be moved at end of the physical line
(in the paragraph direction), it should not be kept in the middle.
If you need to force a linewrap on a non-breaking space (because there's no
other
Dear Richard and Peter,
apologies for the lack of clarity. Let me try to explain below.
On 2018-08-29 01:13, WORDINGHAM RICHARD via Unicode wrote:
On 27 August 2018 at 15:22 Peter Constable via Unicode
wrote:
Layout engines that support CJK vertical layout do not rely on the
'vert' feature
On Tue, Aug 28 2018 at 9:43 -0700, unicode@unicode.org writes:
> On August 23, 2011, Asmus Freytag wrote:
>
>> On 8/23/2011 7:22 AM, Doug Ewell wrote:
>>> Of all applications, a word processor or DTP application would want
>>> to know more about the properties of characters than just whether
>>>
14 matches
Mail list logo
