From: Wolfgang Schuster <wolfgang.schuster.lists@gmail.com>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>,
Emanuel Han via ntg-context <ntg-context@ntg.nl>
Subject: [NTG-context] Re: Japanese
Date: Wed, 28 Feb 2024 22:18:35 +0100 [thread overview]
Message-ID: <f3acdb3d-3df9-f4d6-ac74-a0b550108a37@gmail.com> (raw)
In-Reply-To: <ADE5C64F-50ED-452C-BD1E-0795A377DDC9@getmailspring.com>
[-- Attachment #1.1: Type: text/plain, Size: 5104 bytes --]
Emanuel Han via ntg-context schrieb am 28.02.2024 um 20:51:
> Thank you all for your suggestions and contributions to the wiki.
>
> I don't intend to nag, but when looking at what ConTeXt is producing,
> I need to state that the result is still far away from a properly
> typeset Japanese text.
>
> So the nihongo script which comes with ConTeXt handles *line breaks /
> line wrapping*. But the line break rules defined in it need a rework,
> because they don't follow the standards. The standards are documented
> here:
> https://www.w3.org/TR/jlreq/#possibilities_for_linebreaking_between_characters
> , and all affected characters are listed here:
> https://www.w3.org/TR/jlreq/tables/table_en3.pdf
>
> We have different rules, depending what kind of character is
> surpassing the text width (or is in its last position).
>
> Rule 1:
>
> Before closing brackets, closing quotation marks, iteration marks, the
> Prolonged sound mark and small Kana, line breaking is prohibited.
>
> ’”)〕]}〉》」』】ヽヾゝゞ々ーぁぃぅぇぉァィゥェォっゃゅょッャュョ etc.
>
> The actual programmed behaviour by the nihongo script is that, if in
> the position which exceeds the line width, these characters jump to
> the next line and take the previous character with them. If they're in
> the last position of the line, they stay where they are. This
> behaviour is correct.
>
> Rule 2:
>
> After opening Brackets and opening quotation marks, line breaking is
> prohibited (but not before).
>
> ‘“(〔[{〈《「『【
>
> The actual programmed behaviour by the nihongo script is that these
> characters jump to the next line and take the previous character with
> them. This behaviour is wrong. They should jump to the next line
> without taking the previous character with them, just like any regular
> character. The difference to a regular character is that they jump
> already when still within the line length, and they're in the last
> position of the line. The correct behaviour can be seen in LibreOffice
> Writer in action.
Can you provide a minimal example because this should be correct and if
not it's a bug.
> Rule 3:
> Comma (tōten), full width comma, full stop
>
> 、,。
>
> The actual programmed behaviour by the nihongo script is that, if in
> the position which exceeds the line width, these characters jump to
> the next line and take the previous character with them. This
> behaviour is wrong.
> They have to be put back to the end of the previous line, but beyond
> the specified line length. (JIS Z 8125) (Search for "Line adjustment
> by hanging punctuation" under https://www.w3.org/TR/jlreq/ )
> If they're in the last position of the line, they stay where they are.
> The correct behaviour can be seen in LibreOffice Writer in action.
This is handled by the protrusion mechanism and enabled with paragraph
alignment.
> Rules 4, 5, ...:
> Combinations of inseparable characters... (see
> https://www.w3.org/TR/jlreq/#possibilities_for_linebreaking_between_character
> ) and eventually more, which I didn't test.
>
> It might be useful to define three scripts nihongo_loose,
> nihongo_strict and nihongo_very_strict which each implement one of the
> 3 cases described here: https://www.w3.org/TR/jlreq/#addendum_a
>
> According the *line gap* (Otared uses \setupwhitespace[big], which is
> exceeding common line gaps), I'd like to quote from
> https://www.w3.org/TR/jlreq/ :
>
> /It is common that the line gap for the kihon-hanmen is set to a value
> between half-em spacing and the one em spacing of the character frame
> used for the kihon-hanmen. Half-em spacing can be chosen in cases
> where the line length is short, but one em spacing or close to it is
> more appropriate when the line length is longer than 35 characters./
>
> I like the standard line gap which is provided by ConTeXt, which is
> equivalent to \setupwhitespace/[0pt]/. Even when using ruby, it works
> well. I found the best voffset for ruby to be -1.7ex.
The \setupwhitespace setting controls the distance between paragraphs
but you're looking for the \setuplinespace command.
> The *line adjustment* provided by ConTeXt by default is not meeting
> the needs for Japanese (and Chinese) text, which follow a grid
> pattern. Especially the last line of a paragraph is squeezed, which is
> "hurting the eye".
> When characters need to jump to the next line due to previously
> discussed line breaking rules, ConTeXt seems to apply "Line adjustment
> by inter-character spacing expansion", which is a valid method
> according to https://www.w3.org/TR/jlreq/#line_adjustment , although
> "Line adjustment by inter-character spacing reduction" is preferred.
>
> The last point which ConTeXt is missing, when talking about Japanese
> typesetting, is vertical writing.
Vertical typesetting is possible but only for small text blocks which
fit on a single page. Typesetting text which spans multiple pages isn't
supported yet (it was possible ages ago with MkII) because nobody needed
it yet.
Wolfgang
[-- Attachment #1.2: Type: text/html, Size: 6872 bytes --]
[-- Attachment #2: Type: text/plain, Size: 511 bytes --]
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___________________________________________________________________________________
next prev parent reply other threads:[~2024-02-28 21:22 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 20:08 [NTG-context] Japanese Otared Kavian
2024-02-26 20:16 ` [NTG-context] Japanese Henning Hraban Ramm
2024-02-26 21:49 ` Otared Kavian
2024-02-27 12:55 ` Jeong Dal via ntg-context
2024-02-28 7:34 ` Otared Kavian
2024-02-28 17:34 ` Henning Hraban Ramm
2024-02-28 18:44 ` Jean-Pierre Delange
2024-02-28 19:51 ` Emanuel Han via ntg-context
2024-02-28 20:54 ` Henning Hraban Ramm
2024-02-28 21:18 ` Wolfgang Schuster [this message]
2024-02-29 14:18 ` Jeong Dal via ntg-context
2024-03-01 7:04 ` luigi scarso
2024-03-01 12:08 ` Emanuel Han via ntg-context
2024-03-01 13:59 ` Wolfgang Schuster
2024-03-01 15:23 ` Emanuel Han via ntg-context
2024-03-01 16:19 ` Henning Hraban Ramm
2024-03-02 18:00 ` Wolfgang Schuster
2024-03-10 16:43 ` Emanuel Han via ntg-context
2024-03-10 19:26 ` Jean-Pierre Delange
2024-03-11 22:48 ` Wolfgang Schuster
2024-03-13 14:55 ` Otared Kavian
2024-03-14 7:12 ` Emanuel Han via ntg-context
2024-03-14 13:48 ` Otared Kavian
2024-03-16 8:54 ` Wolfgang Schuster
2024-03-15 8:41 ` luigi scarso
2024-02-26 20:29 ` Hans Hagen
2024-02-26 20:32 ` Emanuel Han via ntg-context
2024-02-26 21:46 ` Otared Kavian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f3acdb3d-3df9-f4d6-ac74-a0b550108a37@gmail.com \
--to=wolfgang.schuster.lists@gmail.com \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).