Meeting minutes
Agenda Review
Action Items
<addison> https://
<addison> #19?
<addison> #15?
<gb> Action 15 Get character styling into w3c stylesheet (on aphillips) due 18 Jul 2023
<addison> #14?
<addison> close #14
<gb> Closed action #14
<addison> #4?
Info Share
JcK: IETF next week, so I probably won't join.
RADAR Review
Pending Issue Review
<addison> https://
Various Pull Requests
addison: Trying to get specdev published.
… Specdev has some broken links, because we haven't publsihed stringmeta in a year.
ACTION: addison: update string-meta in TR
addison: So proposing to publish stringmeta, too.
ACTION: addison to update string-meta in TR
<gb> Created action #24
<addison> w3c/
addison: ^^ about fixing an image. Was this done?
xfq: I think respec was fixed since then, so this can probably be closed.
… I will check.
<addison> w3c/
addison: xfq was adding some Jamo and Kana definitions.
… I noticed a typo.
… I can commit it.
<addison> https://
addison: Shall we look at the two definitions now together?
<xfq> https://
<atsushi> +1 to go
David: I would add that Kana can also be used for emphasis.
… It is not just for loan words.
<xfq> https://
addison: Is Kana really a separate script, or is it a script together with Katakana?
David: In some ways it is also a separate script.
addison: The definition in gloassary is taken from Unicode definition.
atsushi: Maybe too complicated to mention this special usage.
David: Maybe mention hiragana and katakana and not mention the special usages. Example is use in names in metro stations.
addison: So use Unicode def, or...?
<xfq> fwiw, katakana is also commonly used for onomatopoeia
atsushi: I would not mention the complex usages.
David: Suggest to remove "The former is used to write particles, grammatical affixes, and words that have no kanji form; the latter is used primarily to write foreign words."
xfq: (I need to fix some punctuation.)
addison: If we use the Unicode def with chnages, should we inform Unicode?
r12a: higarana and katakana are more often used than kana
xfq: I can mention the two terms and say they are more often used.
David: "PrimariY" syllabic is the right term.
r12a: Or maybe not.
… The second sentence clarifies that the two, hiragana and katakana, are used together, so I'd not remove it.
r12a: I think we need to make our definition, and then tell Unicode.
addison: We can ask Unicode and if they don't want to change, then we can make our own definition.
ACTION: addison to inform Unicode about the kana definition
<gb> Created action #25
xfq: I started writing a def myself, but then found it was very similar to Unicode's, so I used theirs. But I can change it.
addison: I will contact Unicode about the kana definition. And we hold until then.
r12a: Note that is a definition, not meant as a tutorial.
xfq: We can link to other places for that.
atsushi: jlreq spec is frozen and task force hasn't discussed this.
<addison> w3c/
addison: This is about definitions for utf-16 and utf-8.
r12a: is "63K" the right number?
addison: With "k" for 1000?
xfq: Use "2^16"?
addison: I can also mention the utf-16 definition when I talk to Unicode.
xfq: I agree with addison's comment in the issue.
r12a: About the "1M": They are not necessarily less common, or not all of them.
addison: This was written a long time ago and referred to Old Church Slovanic and Arcadian...
JcK: Endianness
… I think no definition is complete without that. Otherwise there are two versions of utf-16.
<xfq> https://
r12a: About utf-8: Maybe say that utf-16 is more used for internal representation and utf-8 for on-the-wire.
addison: I wouldn't say anything in the utf-16 def.
… We might want to say for utf-8 that it is the preferred encoding.
r12a: If you work with javascript, there is ahigh probability you work with utf-16.
xfq: Can say utf-8 is the dominant for the web.
addison: We say in general that you really should use utf-8.
<addison> w3c/
addison: This is about specdev and the rtl/bidi text.
xfq: I only added one "mustard" [about slanting left].
… A few scripts have this requirement.
r12a: Not a requirement for rtl, but for _some_ rtl scripts. Not Adlam, e.g.
addison: Is it "specification" or rather "implementations"?
r12a: If some other spec, say SVG, has a feature to slant text, it should also allow slant to the left.
… Italic usually involves more than slanting. This is about synthesized oblique.
… In that case, if a spec allows slanting, it should also allow slanting to the left.
addison: I would limit it to obliquing.
r12a: We don't have requirements for font developers. This is really only for sythesized oblique.
xfq: Yes, if there is a font, you can just use the font.
addison: Phrase it correctly: not just require slant left, but left and right :-)
r12a: It is not really for text decoration, nor for font management. Maybe park it under miscellaneous for now?
addison: There are some other issues tagged that are not related to obliquing.
xfq: OK, I'll do that
<addison> (for minutes, my suggestion was: Specifications describing the obliquing of text SHOULD support sloping letters in both directions.)
<r12a> https://
xfq: I will move the tags and move the mustard to miscellaneous. And look for other issues for rtl/bidi text.
r12a: About the style for Unicode characers in specs: My code takes the text from the respec style and puts it in the doc. But sometimes it works and sometimes not. Haven't found why yet.
addison: As long as it works when we publish :-)
r12a: We have an index and a local.css. That local.css has stuff specific to that index file and nowhere else. And there is the respec22.css, which is in a different dir and applies to other docs.
… When you publish, the CSS files need to be in the same directory as the index file. So in a way we cheat and copy the from the respec22.css file.
addison: So I should also remove from local.css everything that is in respec22.
r12a: But you also wanted to be able to test things, didn't you?
addison: Yes, it should work not just when we publish.
addison: I want to not have to change things when I publish a doc.
AOB?
<addison> s/Accadian/Akkadian/