You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
แและ·ตัวอย่าง·การเขียน·ภาษาไทย has two many แ characters at the start.
Also, are we sure about the word segmentation for these examples? I tested it by using Firefox to wrap the text, and ended up with the following words:
และ•ตัวอย่าง•การ•เขียน•ภาษา•ไทย
Literally, that means "and sample how write language thai". The current spec word divisions seem to map rather to that of the translation(?)
On Mon, Mar 19, 2018 at 5:47 PM, r12a ***@***.***> wrote:
I'm getting the same segmentation using Chrome and Safari too. Try it:
https://r12a.github.io/pickers/thai/?text=%20%20%20%
20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%20%20%20%20%20%20%20%E0%B9%81%E0%B8%A5%E0%B8%B0%E0%B8%
95%E0%B8%B1%E0%B8%A7%E0%B8%AD%E0%B8%A2%E0%B9%88%E0%B8%B2%E0%
B8%87%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B9%80%E0%B8%82%E0%B8%B5%
E0%B8%A2%E0%B8%99%E0%B8%A0%E0%B8%B2%E0%B8%A9%E0%B8%B2%E0%B9%
84%E0%B8%97%E0%B8%A2
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2455 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAXEwMDQbRrvUJibf2q6uUTz7ny1DnSDks5tf-8tgaJpZM4Swm6f>
.
While we're on this, I wondered if we should make a test case out of this, to make sure that browsers correctly get the dictionary based line breaking, and the impact of word-break on it.
From what I can tell, they already cover what we'd want for this, and the line breaking seems to be done correctly in the first two.
However, the text in the third one seems problematic: just like in the spec sample, it uses แและ. Shouldn't that be และ instead? Also, I suppose that ภาษาไทย ภาษาไทย would be a better sample text than แและ แและแและ.
@r12a@brucelawson Can you confirm? I'll submit a Pull Request for the test as well if needed.
Cool. Let me know when you're done and I'll be happy to review. Meanwhile, could you (or @brucelawson) have a look at the spec PR #2457 and let me know if it's good to merge?
Whether there is a word-break at a particular point is not as clear cut in Thai as in English. At some points, you can say there definitely isn't a word-break, for example, within a syllable. At other points, you can say there definitely is. But there's a large grey area, where native Thai speakers will disagree and it really depends on what you mean by "word" and what you are trying to do. The main grey area is compound words. Compound words are a lot more common in Thai than English, say, because native Thai words (not derived from Pali, Sanskrit, Khmer etc) are mono-syllabic. In a compound word, whether you can have a word break is a matter of degree depending on the semantics: to what extent is the meaning of the compound derivable from the meaning of the components. So for example: การเขียน is a compound word meaning "writing" which is composed from "การ" which is a word that is used to create a noun phrase from a verb and "เขียน" which means to write. There's a little bit more to the meaning of "การเขียน" than it's two components, but not a lot, so breaking between การ and เขียน is not as good as breaking between การเขียน and ภาษาไทย, but is pretty OK and it would depend on the typographic situation as to whether in practise a typographer would break there.
I just looked at a Thai weekly news magazine (Matichon weekly) on my breakfast table, which is set with quite narrow columns, and it breaks compounds quite aggressively (i.e. approximately และ•ตัวอย่าง•การ•เขียน•ภาษา•ไทย). You could even break ตัว•อย่าง but that would start to be a little strange.
Another complication is that what you want for line breaking is not necessarily what you want for selection or cursor movement by word.
Thinking again, I am not quite sure what we should test here, as a smart Thai UA could distinguish between loose/normal/strict to do various levels of breaking, but we're not mandating (or even encouraging) any particular mapping. So I'll remove the "needs test" label.
Clarifying my previous comment: yes, we could still have a test that checks that any of the possible line breaking is allowed, regardless of the loose/normal/strict, but that's not testing anything in particular other than just thai line breaking working in general, which word-break-normal-th-000.html already does.
To be honest, i'd prefer a table here rather than the added complication of a single sentence where the language used for punctuation doesn't seem to be clear (presumably the context is Latin, since a proportional comma is used throughout - though that makes it seem wierd that Latin text doesn't start the example. Also, for example, the comma after the arabic appears to indicate that there's no break point between it and و whereas actually there is a whole bunch of arabic between and the comma should be paired with ی). The table would have the property values down the side, and languages across the top. It would also prevent the double-take i experienced when i saw a period after the last thai word.
added the variations in handling compound words as an example of UA tailoring for line-break values strict vs. loose.
I was actually expecting strict to produce the greater number of break opportunities, rather than fewer, since i intuitively associated strictness with delimiting primitive words. (?) In other words, i'd have expected to see (though i could be wrong):
For example, a UA with sufficiently-advanced Thai language processing ability could choose to map different levels of strictness in Thai line-breaking to these keywords, e.g. disallowing breaks within compound words in strict mode (e.g. breaking ตัวอย่างการเขียนภาษาไทย as ตัวอย่าง·การ·เขียน·ภาษา·ไทย) while allowing more breaks in loose (ตัวอย่าง·การเขียน·ภาษาไทย).
There's no more occurrences of แแ in the document, which is the typo you reported in the OP. If there's another typo you'll have to specify what it is...
To be honest, i'd prefer a table here rather than the added complication of a single sentence where the language used for punctuation doesn't seem to be clear
I could change it to a table, but a large part of the point here is dealing with mixed script text, so I'd rather keep it all in a single paragraph. I've removed all the punctuation, though, to avoid the problems you mentioned. Let me know if this is acceptable.
I was actually expecting strict to produce the greater number of break opportunities, rather than fewer, since i intuitively associated strictness with delimiting primitive words. (?)
The progression is more break opportunities -> less opportunities going from anywhere -> loose -> normal -> strict. I don't think making an exception here to make Thai go backwards is a good idea.
Hello,
I am in this mailing list fairly short time but I would like to ask, if it
is in consideration to add percentage in to transform:scale(). Now it is
taking [-1, 1] without scaling any number of that type. Scaling by
percentage will be nice to have.
Example transform:scale(120%) will work same as transform:scale(1.2) etc.
Thanks for your time
Hi @Ernedar I think you're commenting on the wrong issue. Could you please file a new issue against the Transforms spec? Here's the link for filing a new issue. Please tag it against [css-transforms].
Activity
r12a commentedon Mar 19, 2018
I'm getting the same segmentation using Chrome and Safari too. Try it (reduce the textarea width):
https://r12a.github.io/pickers/thai/?text=%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%E0%B9%81%E0%B8%A5%E0%B8%B0%E0%B8%95%E0%B8%B1%E0%B8%A7%E0%B8%AD%E0%B8%A2%E0%B9%88%E0%B8%B2%E0%B8%87%E0%B8%81%E0%B8%B2%E0%B8%A3%E0%B9%80%E0%B8%82%E0%B8%B5%E0%B8%A2%E0%B8%99%E0%B8%A0%E0%B8%B2%E0%B8%A9%E0%B8%B2%E0%B9%84%E0%B8%97%E0%B8%A2
brucelawson commentedon Mar 19, 2018
[css-text-3] Fix Thai sample
frivoal commentedon Mar 20, 2018
@r12a @brucelawson made a pull request based on your suggested fix. I cannot read thai myself, so please confirm I got it right. #2457
frivoal commentedon Mar 20, 2018
While we're on this, I wondered if we should make a test case out of this, to make sure that browsers correctly get the dictionary based line breaking, and the impact of word-break on it.
It looks like we already have 3 such tests:
word-break-normal-th-000.htmlword-break-break-all-003.htmlword-break-keep-all-003.htmlFrom what I can tell, they already cover what we'd want for this, and the line breaking seems to be done correctly in the first two.
However, the text in the third one seems problematic: just like in the spec sample, it uses
แและ. Shouldn't that beและinstead? Also, I suppose thatภาษาไทย ภาษาไทยwould be a better sample text thanแและ แและแและ.@r12a @brucelawson Can you confirm? I'll submit a Pull Request for the test as well if needed.
r12a commentedon Mar 20, 2018
The reason i noticed the Thai problems in the spec is that i'm currently rewriting those tests and adding to them. :-) I'll send a PR when done.
frivoal commentedon Mar 21, 2018
Cool. Let me know when you're done and I'll be happy to review. Meanwhile, could you (or @brucelawson) have a look at the spec PR #2457 and let me know if it's good to merge?
[css-text-3] Correct Thai example of line breaking. #2455
fantasai commentedon Mar 22, 2018
OK, I asked a friend and she says และ•ตัวอย่าง•การเขียน•ภาษาไทย is correct.
fantasai commentedon Mar 22, 2018
Now the question in my mind is, do we have different rules for typesetting vs handwriting? Or is there something else going on here?
jclark commentedon Mar 22, 2018
Whether there is a word-break at a particular point is not as clear cut in Thai as in English. At some points, you can say there definitely isn't a word-break, for example, within a syllable. At other points, you can say there definitely is. But there's a large grey area, where native Thai speakers will disagree and it really depends on what you mean by "word" and what you are trying to do. The main grey area is compound words. Compound words are a lot more common in Thai than English, say, because native Thai words (not derived from Pali, Sanskrit, Khmer etc) are mono-syllabic. In a compound word, whether you can have a word break is a matter of degree depending on the semantics: to what extent is the meaning of the compound derivable from the meaning of the components. So for example: การเขียน is a compound word meaning "writing" which is composed from "การ" which is a word that is used to create a noun phrase from a verb and "เขียน" which means to write. There's a little bit more to the meaning of "การเขียน" than it's two components, but not a lot, so breaking between การ and เขียน is not as good as breaking between การเขียน and ภาษาไทย, but is pretty OK and it would depend on the typographic situation as to whether in practise a typographer would break there.
I just looked at a Thai weekly news magazine (Matichon weekly) on my breakfast table, which is set with quite narrow columns, and it breaks compounds quite aggressively (i.e. approximately และ•ตัวอย่าง•การ•เขียน•ภาษา•ไทย). You could even break ตัว•อย่าง but that would start to be a little strange.
Another complication is that what you want for line breaking is not necessarily what you want for selection or cursor movement by word.
15 remaining items
frivoal commentedon Oct 3, 2018
Thinking again, I am not quite sure what we should test here, as a smart Thai UA could distinguish between loose/normal/strict to do various levels of breaking, but we're not mandating (or even encouraging) any particular mapping. So I'll remove the "needs test" label.
However, the issue with
word-break-keep-all-003.htmlmentioned in #2455 (comment) is still there, so i've opened an issue to deal with that: web-platform-tests/wpt#13329frivoal commentedon Oct 3, 2018
Clarifying my previous comment: yes, we could still have a test that checks that any of the possible line breaking is allowed, regardless of the loose/normal/strict, but that's not testing anything in particular other than just thai line breaking working in general, which
word-break-normal-th-000.htmlalready does.r12a commentedon Nov 12, 2018
Example 6 at https://drafts.csswg.org/css-text-3/#valdef-word-break-keep-all ? Doesn't look different to me...
To be honest, i'd prefer a table here rather than the added complication of a single sentence where the language used for punctuation doesn't seem to be clear (presumably the context is Latin, since a proportional comma is used throughout - though that makes it seem wierd that Latin text doesn't start the example. Also, for example, the comma after the arabic appears to indicate that there's no break point between it and و whereas actually there is a whole bunch of arabic between and the comma should be paired with ی). The table would have the property values down the side, and languages across the top. It would also prevent the double-take i experienced when i saw a period after the last thai word.
r12a commentedon Nov 12, 2018
I was actually expecting
strictto produce the greater number of break opportunities, rather than fewer, since i intuitively associated strictness with delimiting primitive words. (?) In other words, i'd have expected to see (though i could be wrong):[css-text-3] Remove punctuation from example since it's confusing wit…
fantasai commentedon Dec 4, 2018
@r12a
There's no more occurrences of แแ in the document, which is the typo you reported in the OP. If there's another typo you'll have to specify what it is...
I could change it to a table, but a large part of the point here is dealing with mixed script text, so I'd rather keep it all in a single paragraph. I've removed all the punctuation, though, to avoid the problems you mentioned. Let me know if this is acceptable.
The progression is more break opportunities -> less opportunities going from
anywhere->loose->normal->strict. I don't think making an exception here to make Thai go backwards is a good idea.Ernedar commentedon Dec 4, 2018
fantasai commentedon Dec 4, 2018
Hi @Ernedar I think you're commenting on the wrong issue. Could you please file a new issue against the Transforms spec? Here's the link for filing a new issue. Please tag it against [css-transforms].
fantasai commentedon Jan 15, 2019
@r12a Could you confirm whether #2455 (reference) and the ensuing comment address your remaining concerns in this issue?
r12a commentedon Jan 28, 2019
Yes. Thanks.
Btw, fwiw, there are a set of exploratory, interactive test pages linked from https://w3c.github.io/i18n-tests/results/exploring-linebreak, which includes a test for Thai.