00:24:26 RRSAgent has joined #css 00:24:26 logging to http://www.w3.org/2009/03/04-css-irc 00:24:30 RRSAgent, make logs public 00:24:33 trackbot, start telcon 00:24:35 RRSAgent, make logs member 00:24:35 Zakim has joined #css 00:24:37 Zakim, this will be Style_CSS FP 00:24:37 I do not see a conference matching that name scheduled within the next hour, trackbot 00:24:38 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:24:38 Date: 03 March 2009 00:24:46 RRSAgent, make logs public 00:24:50 zakim, remind us in 8 hours to go home 00:24:50 ok, ChrisL 00:25:42 http://www.w3.org/Style/Group/2009/Tokyo.html 00:30:13 Topic: Media Queries 00:30:18 Scribe: Hakon 00:31:19 scribenick: howcome 00:33:36 szilles has joined #css 00:35:46 Chris: specific MQ issues? 00:35:47 RRSAgent, make minutes 00:35:47 I have made the request to generate http://www.w3.org/2009/03/04-css-minutes.html MikeSmith 00:35:53 Anne: several comments have been made 00:36:21 Anne: Dean Jackson has proposed changes in aspect-ratio syntax 00:36:24 Dan Jackson asked for syntax changes in some queries 00:36:43 http://lists.w3.org/Archives/Public/www-style/2008Dec/0019.html 00:37:03 http://lists.w3.org/Archives/Public/www-style/2008Oct/0328.html 00:37:18 howcome: aren't we dropping these 00:37:30 Anne: they're marked at risk 00:38:12 Anne: I would be fine dropping the features at risk, and keep orientation unchanged 00:38:46 shinyu has joined #css 00:39:14 shinyu has joined #css 00:39:19 Anne: the use case is to have a DOM interface to the orientation 00:39:39 masayuki has joined #css 00:41:03 portrait or landscape is much more useful 00:41:33 steve: is there a square pixel issue involved? 00:42:07 dbaron: 3.1 supports aspect-ration 00:42:14 s/ration/ratio/ 00:42:16 Anne: s/the use case/the use case for degrees/ 00:42:39 Chris: If you're using it for games and things, then you also want to know the tilt, the acceleration, etc. Just make another API 00:43:02 dbaron: the use case for device-aspect-ration is weak 00:43:06 Steve: In that case you'd want landscape/portrait in addition to the orientation angle 00:43:17 dbaron: the use case for device-* is weak 00:43:31 dbaron: but we implement both aspect-ratio and device-aspect-ratio 00:43:38 s/device-aspect-ration/device-*/ 00:45:03 I could see a stylesheht that gave 4 columns for a 16:9 landscape and 3 for 4:3 00:45:10 s/shet/sheet/ 00:45:36 fantasai: one use case is having more columns if the display is wide 00:46:08 s/sheht/sheet/ 00:46:37 anne: in that case you care about the width 00:46:46 fantasai: Not if you're doing a presentation that scales to fill the space 00:47:10 steve: if I have several images, I could select the right one to fill the sceen 00:47:43 steve: I thought we went through this in great detail, why are we discussin this? 00:47:58 annevk: apple has proposed a syntax change 00:48:21 dbaron: given that we now support exact matching, we should stick to our current syntax 00:48:46 yes, trying to match on a float is liable to error 00:51:40 howcome is skeptical that aspect-ratio is useful 00:51:56 fantasai: you can use it to select a different video, widescreen vs fullscreen 00:52:33 anne: device-aspect-ratio would be useful for videos too 00:52:54 shinyu: http://krijnhoetmer.nl/irc-logs/ 00:53:22 fantasai: Media queries are used for more than just CSS 00:54:02 Chris: Mozilla and Opera both implement it 00:54:04 common industry use is ratio - 16:9, 16:10, 4:3 not 1.623 00:54:20 so we have implementations in firefox, opera and webkit 00:54:41 resolved: no current changes 00:55:23 chrisl: any other comments? 00:55:27 RESOLVED: Keep aspect-ratio and device-aspect-ratio, no changes to syntax 00:55:55 annevk: some editoral comments, some comments on tty 00:57:05 annevk: we don't clarify what px unit means for tty devices 00:59:52 annevk: that clarification should possibly go into the Values and Units draft 01:00:52 there was one about malformed queries 01:00:53 http://lists.w3.org/Archives/Public/www-style/2008Dec/0064.html 01:01:40 chrisl: is there as disposition of comments? 01:02:07 annevk: I can add the new issues to the previous disposition of comments 01:02:35 dbaron: what's the issue with the formal grammar 01:02:53 http://www.w3.org/mid/Pine.LNX.4.63.0902242324240.6949@master.abisoft.spb.ru 01:05:26 howcome: so, it seems we currently can't take all grammars in all CSS specs, concatinate them and have something valid comes out 01:05:34 steve: the formal grammar is only a hint 01:06:27 jdaggett: there are things that cannot easily be expressed in formal grammars 01:06:50 szilles: do we say anywhere what the goal of the formal grammars are? 01:07:22 howcome: HTML5 writes it out in prose 01:07:32 Mike: by desing 01:07:43 s/desing/design/ 01:19:52 sylvaing has joined #css 01:20:17 jdaggett has joined #css 01:20:23 ChrisL has joined #css 01:20:32 szilles has joined #css 01:20:35 anne has joined #css 01:20:40 hi 01:20:46 The spec could state that, due to grammar overrides in the prose, the grammar is not sufficient by itself for creating a parser 01:20:48 The snapshots could collect together the 2.1 grammar plus the patches defined in each odule, to goive a consistent grammar 01:20:55 dbaron has joined #css 01:21:01 masayuki has joined #css 01:21:17 howcome has joined #css 01:21:25 annevk: i agree with the comment that the css grammar is rather hacky 01:21:41 dbaron: if we think this is important, somebody should sit down and think about it 01:21:46 fantasai: the grammar could be described in a snapshot 01:21:50 annevk: the alterative is for MQ to define its own grammar, like the CSS selectors spec 01:21:55 steve: there are selveral pieces to this: all the bits are not meant to go into a grammar generator 01:22:08 rrsagent, here 01:22:08 See http://www.w3.org/2009/03/04-css-irc#T01-22-08 01:22:32 Meeting: CSS WG f2f, Tokyo 01:22:32 szilles_ has joined #css 01:22:37 Chair: Chris 01:23:37 MikeSmith has joined #css 01:24:10 fantasasi: the productions for one specific module is prefixed with an identifier specific to the module; if a production is intended to replace an existing one, this will be marked 01:24:15 s/ odule/ module/ 01:24:21 s/fantasasi/steve/ 01:24:38 s/black/white/ 01:24:43 s/good/bad/g 01:26:38 fantasai: anne can either define a grammar for MQ or resolve the differences with the global grammar. 01:28:14 chrisl: somebody has to sit down and propose a solution 01:28:50 RESOLVED: anne can choose to either define a grammar for MQ or resolve the differences with the global grammar 01:30:46 I don't think we have anything to discuss with namespaces, just need implementation reports 01:31:02 The test suite went through a very meticulous review process and has already been published. 01:58:16 Topic: Paged Media 01:59:04 http://lists.w3.org/Archives/Public/www-style/2009Mar/0005.html 02:01:57 So, its not possible to select the initial containing block and set its size (and then set the margins to be auto) 02:02:15 ee: can set the document root element to be a fixed width 02:15:11 dbaron has joined #css 02:15:50 jdaggett has joined #css 02:16:12 szilles has joined #css 02:17:26 anne has joined #css 02:17:50 MikeSmith has joined #css 02:19:06 sylvaing has joined #css 02:23:47 jdaggett: 基本半面 in Japanese? 02:24:22 hmmm 02:24:32 check jp version? 02:25:26 http://lists.w3.org/Archives/Public/www-style/2009Mar/0005.html 02:25:35 thanks 02:26:07 基本版面 02:26:19 MikeSmith: ^ 02:26:49 hmm, OK 02:26:50 thanks 02:30:42 ChrisL has joined #css 02:32:08 so seems like it's 基本版 as as unit modifying 面 .. translates as "baseline page" 02:33:34 compound noun, no? 基本 + 版面 02:34:58 rrsagent, here 02:34:58 See http://www.w3.org/2009/03/04-css-irc#T02-34-58 02:37:43 jdaggett: I never seen the word 版面 ... trying to figure out what it might mean 02:39:05 http://ext.dictionary.goo.ne.jp/leaf/jn/160482/m0u/%E7%89%88%E9%9D%A2/ 02:39:26 masayuki has joined #css 02:39:35 ah, template, I guess? 02:40:26 Discussion of kohon hanmen and Japanese layout. 02:40:26 Elike summarizes what is meant by "kihon hanmen". 02:40:26 It refers to three things: 02:40:26 1. The box that is the equivalent of the page area, 02:40:26 i.e. the box in which the content is laid out on 02:40:28 the page. 02:40:31 2. The settings used to arrive at the size of this 02:40:33 box, namely: 02:40:36 - font-size 02:40:38 - number of columns per page 02:40:41 - column gap 02:40:43 - width of column 02:40:46 - line gap 02:40:48 - number of lines per page 02:40:51 3. The grid formed by those settings ... 02:40:53 Murakami-san writes: 02:40:56 @page { 02:40:58 margin: auto; 02:41:01 width: 40em; 02:41:03 height: calc(20*16pt); 02:41:06 font-size: 10pt; 02:41:08 line-height: 16pt; 02:41:11 } 02:41:14 Murakam-san explains that in Japanese layout, you start 02:41:16 with the kihon hanmen, and then center it within the page, 02:41:19 or specify one side of the margin and let the other margin 02:41:21 be auto. Suggests a unit for line-height would be useful. 02:41:24 fantasai suggests that allowing @page to accept width and 02:41:26 height should be sufficient. The author (or authoring tool) 02:41:29 may have to do so some math to get the width and height of 02:41:31 the kihon hanmen from the settings, but then the margin 02:41:34 auto positioning should work. 02:41:36 dbaron suggests the rem unit might be useful here 02:41:39 Discussion of whether font-size and line-height in @page 02:41:42 should affect the root element. No, it should not. 02:41:44 Should @page inherit from the root element? 02:41:47 Murakami-san writes column-count, writing-mode, and column-width 02:41:49 into the @page rule. Discussion of page-based templates. 02:41:52 Chris: So the bit of consensus that I heard was that 'width' and 'height' can be used on @page 02:41:55 Steve: Also inheritance is as before, the :root element is the top of the inheritance chain and does not inherit from anything else 02:47:34 Discussion of copying values between @page and :root 02:47:45 fantasai does not want inheritance from @page to :root 02:47:54 fantasai suggests inheritance from :root to @page 03:02:54 Lots of discussion about page templates and getting @page templates to match up with elements in the tree 03:03:06 e.g. an Appendix template that matches up with
03:03:59 Proposed resolutions: 03:04:24 1. Apply width and height to the page box, following rules in CSS2.1:10 wrt calculating margins 03:04:34 2. @page inherits from the root 03:05:03 3. Synchronization between named page templates and content deferred until later 03:10:15 fantasai explains that because the print industry is relying on css3-page for their own standards, we may need to add loopholes that allow implementations to be conformant if they don't do the above 03:12:57 RESOLVED: 'width' and 'height' apply to the page box, follow rules in CSS2.1:10 wrt calculating margins. This behavior is at-risk. 03:14:11 RESOLVED: @page inherits from the root. B/c this was not defined in previous CR, conformant implementations may instead use the initial value 03:15:40 s/Synchronization/Synchronization of property values/ 03:28:26 Murakami-san shows an example where different parts of the document have different kihon-hanmen 03:29:05 fantasai writes up an example that uses just the new 'width' resolution and named pages to accomplish this use case 03:29:25 Steve suggests adding fantasai's example to the spec 03:29:28 Example is: 03:29:30 03:29:32 03:30:33
...
03:30:39
...
03:30:40 03:30:45 @page { margin: auto; } 03:30:55 @page main { width: 61em; } 03:31:01 @page index { with: 62em; } 03:31:23 ACTION: fantasai add this example to the spec 03:31:24 Created ACTION-125 - Add this example to the spec [on Elika Etemad - due 2009-03-11]. 03:31:46
04:26:13 dbaron has joined #css 04:28:33 sylvaing has joined #css 04:28:41 jdaggett has joined #css 04:30:26 dbaron has joined #css 04:32:01 ChrisL has joined #css 04:35:52 Introductions 04:37:13 Joined by 04:37:16 Kobayashi-sensei 04:37:21 Kobayashi-san 04:37:26 Yasuhiro Anan-san 04:38:04 Tatsuo Kobayashi-san, Justsystem, chair of JLTF 04:38:19 Anan-san, Microsoft, will be translating for Kobayashi-sensei 04:39:24 szilles_ has joined #css 04:42:14 EE: offers to discuss the specs that are relevant to the JLTF requirements 04:42:21 anne has joined #css 04:42:31 EE: there are 3 relevant spects plus GCPM 04:42:39 s/spects/specs/ 04:43:08 EE: the first spec is Paged Media that covers the description of the page, its margins, headers and footers, ... 04:44:03 EE: there is a default page, plus pages forfirst, left and right pages and a set of named pages. 04:44:45 EE: the content has to fit inside the page box else it gets clipped 04:46:47 EE: the current Paged Media model does not have a concept of "spread" (that is two facing pages together), that is a topic for a future version. 04:48:09 K-san: what about line-staking-strategy? 04:48:56 Note to self: css3-page should not clip to the page area, but to the padding box of the page box 04:50:15 DB: Some of the goals of the line box module are contradictory; e. g., since an author cannot really know what font (and other) resources will acctually be used. 04:51:26 DB: the current line stacking rules are not ideal for Western topography and they certainly do not consider things like Rugy annotations. 04:52:34 Discussion of line-stacking-strategy 04:52:47 dbaron: The current rules aren't even ideal for Western typogrpahy 04:53:23 dbaron: We might want different options for what gets considered 04:54:29 Anan-san, Kobayashi-san: ruby above the first line spills outside the kihon hanmen 04:54:52 Steve: Do we flag this as an issue to come back to later? 04:55:32 fantasai: yes. We don't have anyone working on a module that involves this. Nobody will be able to fix it within the next 6 months 04:56:36 K-san: figure 37 of the current JLTF draft shows the ruby outside the Kihonhanmen on the first line. 05:00:52 dbaron asks if the ruby crosses the midline between two lines 05:00:54 yes, it does 05:00:58 The current JLTF draft is 05:01:00 http://www.w3.org/2007/02/japanese-layout/docs/aligned/japanese-layout-requirements-en.html 05:01:10 Kobayashi-san: The line gap is usually smaller than the line width, e.g. 2/3 05:01:24 Kobayashi-san: Ruby is usually 1/2 the size of the font size 05:03:06 K-san and K-sensei: the ruby chars are set without and "leading" between the base characters and the ruby characters; this assumes internal leading in the fonts. 05:03:11 Anan-san: The current MSFT implementations grow the line-height to accommodate ruby, but this is not correct 05:03:22 Anan-san: the ruby characters should fit within the line-gap 05:03:23 masayuki has joined #css 05:07:28 SZ: One reason that line-stacking-strategy was created was to allow a user to specify whether he wanted to guarantee that no overlap (the CSS rule) or he wanted to guarantee consistent spacing between lines 05:08:27 SZ: Since CSS tries to guarantee no overlap of lines, it would be reasonable to have the Ruby chars taken into account in determining the actual line height. 05:09:23 EE: CSS3 Page module covers margin boxes, their position, their content 05:09:47 EE: for styling the boxes the many of the normal CSS properties can be used. 05:10:09 EE: page numbers can be inserted 05:10:27 EE: various paper sizes can be selected 05:11:28 EE: the current rules in Paged Media select the paper size, and determine the page area by setting values for the margins. This does not guarantee a specified numbers o lines or line lengths 05:13:42 EE: this morning we proposed that Paged Media would allow explicit setting of the Width and Height using the rules of CSS2.1 section 10 05:15:37 EE: this allows explicit setting of the Kihonhanmen size in EMs and centering the resultant area on the paper. 05:16:47 EE: named pages provide a kind of styling template that can be applied to different sections of the content (using selectors) 05:17:55 EE: The second document is CSS Text which is, itself, not a complete module (it is an extract of a prior module. 05:18:49 EE: it covers wihite space control, line breaking and word boundaries. 05:19:24 EE: We know that Japanese has its own line breaking rules which are different than western text rules. 05:20:05 EE: There are some named rules for controlling line breaking 05:22:47 Anan-san: Appendix 3 of the JLTF document has an explicit description of line-breaking for Japanese based on character classes 05:25:13 Anan-san: There are at least two sets of rules for line breaking: basic ones such as the Unicode line breaking rules 05:26:46 Anan-san: and stricter rules that cover a more complete set of cases, such as those in Appendix 3 of the JLTF report 05:27:27 Anan-san: for example, Firefox does a better job of handling rules than some other implementations 05:29:02 Anan-san: Microsoft Word adopted an earlier version of the rules in JIS4051 and, therefore, allows some breaks that would not be expected. 05:31:04 EE: for western text, there are 2 options, break where allowed by the language and break anywhere (including inside a word) 05:32:19 EE: for japanese, there are also two options: loose and strict, with strict being the default. Specifying what these mean, however, is a problem. 05:33:40 Murasaki-san: breaking before small kana is fairly common in Japanese 05:38:39 szilles has joined #css 05:38:45 Kobayashi-san: There are three levels: newspaper level, magazine level, book level 05:38:53 There are 3 levels: newspaper level, magazine level and book level 05:38:59 Murakami-san: Many books use normal level, not strict level 05:39:01 jdaggett has joined #css 05:39:12 dbaron has joined #css 05:39:20 masayuki has joined #css 05:39:33 Kobayashi-san discusses house rules 05:39:33 There are also "house rules" used by a particular publication house 05:39:51 Perfect line breaking rules for English probably don't exist either. Consider finding the allowed breaks in bis(4-chlorophenyl)-1,1,1-trichloroethane 05:39:58 K-san: we do not, however, need to have rules at that level of detail 05:40:10 Kobayashi-san: Although some implementations use house rules, we can still define some base levels 05:40:29 Murakami-san writes: loose, normal, strict 05:42:16 K-sensei: there are 4 options: loose, normal, strict and very-strict 05:43:03 sylvaing has joined #css 05:44:22 very-strict forbids breaks before small-kana, the sound lengthen mark and decoration marks. 05:45:17 K-san: almost all publications do not not use very-strict 05:45:49 From now on we will use levels 1,2,3 and 4 where 4 is most strict and 1 is least strict 05:46:26 level 4 is not often used. 05:48:46 K-san agrees that the JLTF will define the rules for the 4 classes of line-breaking rules. 05:49:42 EE: could we also get a textual summary of the rules that would give an author an sense of what to expect without tracing thru the table? 05:50:36 EE: which level is the default level? 05:50:52 K-san/K-sensei: level 3 is the default 05:55:58 EE: do these breaking rules also cover numbers and foreign language text? 05:57:54 EE: for example, there is a property value that applies to latin text that allows breaking anywhere within a word. This occurs, for example, in Korean usage. 05:58:37 K-san/K-sensei: Japanese link-breaking does not allow line-breaking inside a word. 06:22:22 jdaggett has joined #css 06:24:18 jdaggett has joined #css 06:24:26 jdaggett has joined #css 06:25:39 jdaggett has joined #css 06:29:34 szilles_ has joined #css 06:31:04 masayuki has joined #css 06:33:06 anne has joined #css 06:34:29 Resuming after a break 06:34:35 ChrisL has joined #css 06:34:57 dbaron has joined #css 06:35:05 EE: The WG thanks the JLTF for agreeing to provide us guidance on line breaking 06:35:06 We also need to keep the line-breaking compatible with English. :-) 06:35:52 EE: text-wrap gives control over chuncks of text beyond the word level 06:36:08 dictionary-based English hyphenation ftw! 06:36:43 EE: Alignment (horizontal) controls aligning to start, end, center, justify and control over last line as well 06:37:53 jdaggett_ has joined #css 06:40:09 EE: in CSS, a single line is also a last line. 06:40:43 jdaggett has joined #css 06:41:30 EE: because a window can always be resized, one cannot guarantee that a "single line" will fit within the window so ti would be justified in two or more lines unless wrapping is forbidden 06:43:15 glazou has joined #css 06:43:54 Issue: text-align-last: justify center; 06:43:54 Created ISSUE-97 - Text-align-last: justify center; ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/97/edit . 06:44:09 Murakami-san: if there is only one character on the last line where is it placed with Justtify? 06:46:30 EE: there is control over which space adjustments are used for justification: 06:51:02 Anan-san: How does "inter-graphemic" apply to east asian languages? 06:51:44 Many: it is there primarily for scripts like indic scripts that have grapheme clusters. 06:52:41 Anan-san: Japanese characters with diacrictics for voicing do form a grapheme 06:54:30 sylvaing has joined #css 06:55:17 Issue: If the same about of extra space that is being used between full width characters (for justification) is also put between half width characters, then the alignment of two half width characters with one full width character will be broken. 06:55:17 Created ISSUE-98 - If the same about of extra space that is being used between full width characters (for justification) is also put between half width characters, then the alignment of two half width characters with one full width character will be broken. ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/98/edit . 06:56:19 (I asked a few minutes ago what happens with halfwidth characters and justification.) 06:56:43 ISSUE: make sure justification allows not justifying between various bits of punctuation 06:56:43 Created ISSUE-99 - Make sure justification allows not justifying between various bits of punctuation ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/99/edit . 06:56:44 Anan-san: the vertical kana repeat mark upper half should not be split from the lower half mark during justification 07:00:40 JD: In implementation that use the typographic data in a font should not be considered non-conforming 07:01:11 s/implementation/implementations/ 07:01:27 s/In i/I/ 07:01:47 EE: there is spacing that does "tracking" 07:02:19 EE: Word spacing does not (should not) apply to the Ideographic Space. 07:04:34 Anan-san: Tsumegumi controls the reduction of spaces between characters up to the collision of the glyphs 07:06:29 JD: letter spacing is problematic becuase when kerning is involved you want a multiplicative property rather than a adative one. 07:06:55 EE: the current design has a percentage of the letter space; what is wanted? 07:08:38 JD: what is desired for letter spacing is to add/subtract a percentage of the character advance rather than a fixed amount between all characters. 07:08:52 Issue: percentage should be wrt character advance, (before or after kerning?) 07:08:52 Created ISSUE-100 - Percentage should be wrt character advance, (before or after kerning?) ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/100/edit . 07:09:04 Note that kerning changes the advance between certain characters 07:09:24 Steve says after kerning 07:12:42 fantasai: that would create uneven spacing in, e.g. "filling" 07:12:54 "milling" 07:12:58 "Anyone who would letterspace blackletter would steal sheep." 07:13:29 SZ: the specification of these properties should not require the implementation of bad typography; it should allow an implementation to do "better than a minimum level" 07:13:53 fantasai, so why are you introducing a new feature (% letter spacing) if you don't think it does something reasonable? 07:14:19 EE: with evenly spaced tsumegumi, how do measure the space added or subtracted? 07:16:00 fantasai, we're missing a measurement that accounts for the character advance width 07:16:05 discussion: the tracking value is not applied to the full character advance, but (in an as yet undefined way) to the space between characters after kerning is done 07:16:13 fantasai, so I picked a way to reference the advance with of a space character 07:16:23 s/fantasai,/dbaron,/ 07:16:38 dbaron, right now you can reference ems 07:16:52 dbaron, but that gives weird results if you compare a narrowly-designed font with a widely-designed one 07:18:12 a;nan-san/K-sensei: the tsumegumi can be specified in ems because the amount is typically a percent of the font size. 07:18:50 anan-san: the letter-spacing applied to cjk would usually be too much for latin 07:19:00 anan-san: so you may need a way to separate 07:19:42 Anan-san/K-sensei: when a line has mixed latin and ideographic text the space adjustments are not uniform across the line but are different for the different kinds of text 07:23:03 CL: rather than have different letter spacing values for each language, it would be better to markup each section of text with its language and use selectros to apply differn letter spacing values to the different spans 07:26:10 K-san: I like CL's solution because it also handles cases where in a span things liek the font-size is changed and the letter spacing needs to change. 07:26:54 EE: but, there will be cases where the foreign text is not marked up and there needs to be a way to deal with those cases. 07:27:22 arronei has joined #CSS 07:28:17 K-san: tsumegumi like this is usually only used for short bits of text in large fonts, such as headings 07:28:23 K-san: so this solution should be sufficient 07:28:30 EE: trying to use Unicode ranges to control the letter-spacing is not a good idea because it does not deal with punctuation characters 07:30:54 EE shows definition for punctuation-trim 07:31:15 jdaggett: is this in addition to or instead of kerning? 07:33:28 jdaggett: if the font is already doing this kerning, we can't tell 07:33:55 anan-san: Also, the same Unicode code-point is different depending on what language the font was designed for 07:37:58 k-san: Three issues interrelated: where to break the line, where to position characters by default, where to adjust (justify) the line 07:39:46 szilles_ has joined #css 07:39:53 k-san: There are several places to solve the issue. The CSS level, the font level, ... 07:40:14 k-san: Justsystem and MSFT, between ours the handling of parentheses is slightly different 07:40:54 s/.../OS-level/ 07:41:12 k-san: CSS should explicitly define its position, this will be helpful to other parties 07:41:43 anan-san: Technically we can define the pairs at the font level, but once you put the characters in the line you may want different results 07:41:52 earlier lost data: 07:41:58 EE: punctuation-trim property - this handles the conversion of full width punctuation to half width 07:42:11 JD: asks how this interacts with information in kerning tables in the fonts 07:42:23 It is really hard to know if such kerning data is in the font which makes it difficult to tell whether the lower level enging (e.g. Uniscribe) will do the xform or not. 07:42:43 melinda has joined #CSS 07:43:13 EE: so do we assume the font is wide or not? 07:45:24 no real answer 07:45:33 Murakami-san: Antenna House implements punctuation-trim 07:45:42 Murakami-san: It applies only to CJK fonts 07:45:48 Murakami-san: That have fixed-em width 07:45:57 Murakami-san: full-width brackets only 07:46:06 Murakami-san: Not applied to narrow punctuation 07:46:22 Murakami-san: Interaction with kerning is not a problem. 07:46:35 EE: how do you know if it's full-width? 07:46:55 Murakami-san: MS Mincho has full-width fixed-width glyphs for punctuation 07:47:07 Murakami-san: But MS P Mincho has narrower glyphs for Japanese punctuation 07:47:20 Murakami-san: Antenna House punctuation-trim controls MS Mincho, but not MS P Mincho 07:47:58 jdaggett: With a proportional font, the "half-width" characters are proportionally spaced 07:48:09 jdaggett: whereas in a full-width font they are not (end of summary of P vs not P) 07:48:34 K-san: In Unicode, fullwidth punctuation marks usually have half-width default size 07:48:44 K-san: in the JLTF document 07:49:13 K-san: In Japanese typsetting tradition, especially hot-metal era, usually the punctuation marks are 1/2 em size 07:49:26 K-san: So when the punctuation mark need to be 1em we add 1/2em space 07:49:45 K-san: Steve and us made 6 hours discussion on this at the last meeting 07:50:06 K-san: And we decided to describe every punctuation mark as 1/2 width size as a default 07:50:13 K-san: And with some other half-width space added 07:50:20 K-san: Our document is based on such an agreement 07:50:56 Steve: The reason that the discussion took 6 hours was primarily because there were several kinds of terminology being used in different parts of the document 07:51:18 Steve: this contributed confusion on the part of the non-Japanese speakers who were tyring to read the document and weren't sure how many different principles were used 07:51:32 Steve: So we picked one that made sense to the ppl writing the document and use that consistently 07:52:39 jdagget: Fonts, and OpenType especially, have many ways of doing the same thing. E.g. kerning 07:55:47 Lachy has joined #css 08:02:06 Murakami-san: professional Japanese fonts use fullwidth pucntuation 08:02:49 discussion of P Gothic black magic 08:04:00 Anan-san: You can do pairs kerning in Uniscribe, but it's performance-expensive 08:04:05 Anan-san: ... 08:04:20 jdaggett: FF uses Uniscribe for a lot of text rendering 08:04:29 jdaggett: for desktop, it's ok 08:04:41 jdaggett: for mobile device, ehhh 08:05:11 Murakami-san: Meiryo also has fixed full-width punctuation 08:05:20 Murakami-san: even though Latin is proportional 08:09:36 K-san: the JLTF is willing to consider having levels w.r.t the punctiuation-trim as will be done for line-breaking 08:10:35 EE: the CSS WG has to explain the requirements for punctuation-trim in a way that implementers can implement it. 08:12:02 EE: underline position does not really support Japanese because the convention in Japanese is to use underlines on horizontal text and before-edge lines in vertical text 08:14:50 K-san: the spacing of the "underline" relative to the character box is up to the implementation; they may or may not be useful information for this in the font. 08:15:26 K-sensei: Kendots should be used only for vertical text 08:18:21 K-san: there are two code point for the dots; it is the context of usage, horiz or vert, that determines which glyph is used, independently of which code point is used to represent the dots 08:19:05 Note, also, that the "dots" do not occur in the content, they are generated by CSS UA. 08:24:51 ChrisL, you asked to be reminded at this time to go home 08:26:19 good idea 08:27:37 K-san/K-sensei: w.r.t. middle dot or the accent character, the normal size of the full width character is used, but 1/4 em is trimmed off the top and bottom of the character in a dot above the character or from the left and right of the character in a dot on the before edge. 08:30:33 K-sensei: Ruby and dots will not be used together; therefore dots should be ignored (for Japanese) if specified with ruby. 08:32:13 K-sensei: if text with Ruby annotation is to be emphasized, it can be done by using brackets before and after the emphasized text 08:32:53 EE: Hanging Punctuation has 3 values 08:33:21 http://lists.w3.org/Archives/Public/www-style/2007Oct/0204.html 08:33:37 Start allows the bracket to occur prior to where the first non-punctuation character is to occur 08:33:48 End does the same for the last line 08:34:15 Murakami-san presents his proposal 08:34:17 end-edge allows hanging on end of every line 08:36:21 CL: is there a use case for "start-edge" in analogy to "end-edge" 08:37:46 EE: if there is an indent of the first line, then hanging means into the indent space, not the content area. 08:38:58 EE: what punctuation characters are allowed to hang with "end-edge"? 08:39:37 Zakim has left #css 08:40:38 Murakami-san/K-sensei: only 4 characters (stop, ideographic stop, comma and ideographic comma) can hang with "end-edge" 08:43:56 Murakami-san/EE: for "start" the punctuation that hangs are opening brackets and quotes; for "end" they are ending brackets and quotes. 08:44:21 It was ageed that there is no Japanese use case for "start-edge". 08:50:03 end should have end-auto functionality 08:50:15 forcing the punctuation to hang should be 'force-end' 08:51:02 K-sensei: there is a requirement for a "forced-end" value which forces the final stop to be hanging and then justifies the chararacters that remain on the line. 08:56:21 EE and Murakami-san: In the above discussion, replace "end-edge" with "end"; replace "start" with "first" and "end" with "last" 08:57:49 glazou has joined #css 08:58:17 This renaming leaves "forced-end" meaning that the hang is forced on any line that ends with one of the four punctuation symbols that can hang with "end" 09:01:51 MikeSmith has joined #css 09:02:30 Murakami-san suggests maybe 'end' might be confusing with 'forced-end' for Western typographers 09:03:01 Western typography typically only hangs the hyphen, and it's not common 09:03:13 Suggestion: 'allow-end' 'forced-end' 09:03:40 Other suggestion, need 'hypens' value? since Japanese doesn't hang hyphens 09:04:55 Meeting closed 09:05:17 EE: suggests that "end" be called "allow-end" to make it relationship to "force-end" to be more clear. 09:05:38 At 6:10, the meeting adjourned for the day. 09:09:07 RRSAgent, make minutes 09:09:07 I have made the request to generate http://www.w3.org/2009/03/04-css-minutes.html MikeSmith 09:09:27 have a nice evening 09:09:52 RRSAgent, make logs public 09:15:14 anne has left #css 09:21:24 masayuki has joined #css 10:09:58 A has joined #Css 10:57:12 myakura has joined #css 12:11:03 dbaron has joined #css 12:32:50 szilles has joined #css 12:38:23 szilles__ has joined #css 13:03:19 sylvaing has joined #css 13:36:21 annevk has joined #css