headers
John Daggett | 1 Jun 2009 09:25

Re: <at> font-face and unicode-range

Hi Michael,

> Recently we have been updating Prince so that  <at> font-face rules are
> handled as described in the latest draft of the CSS3 Fonts module and
> we have also added support for the unicode-range descriptor.

Great, fantastic!

> - Should the spec include keywords for common Unicode blocks?
> 
> The TrueType OS/2 table includes a UnicodeRange field that describes
> the coverage of several common Unicode blocks, eg. basic_latin,
> latin1_supplement, greek_and_coptic, and so on. Something like this
> could be a useful addition to the spec that would make it easier for
> authors than writing explicit codepoint ranges.

This is a good improvement I think but maybe it would be better to just
add a string value to the possible values of <urange>.

unicode-range: "Basic Latin", U+1??;

The list of ranges in the OS/2 table seems to be based on named ranges
in the Unicode standard, I'll see if I can find a definitive source for
this.

>   - Is it worth allowing single character strings to identify codepoints?
> 
> For example, 'a' or '\61' could be used as a synonym for U+61. This
> might be easier for people familiar with CSS syntax. It doesn't help
> with the other ranges though, unless 'a'-'z' is also allowed.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Michael Day | 1 Jun 2009 10:18
Favicon

Re: <at> font-face and unicode-range

Hi John,

> This is a good improvement I think but maybe it would be better to just
> add a string value to the possible values of <urange>.

That's a good idea. The definitive source for Unicode block names would 
be the Blocks.txt file, eg. for Unicode 5.1:

http://unicode.org/Public/UNIDATA/Blocks.txt

It also includes some rules about matching block names, stating that 
casting, whitespace, hyphens, and underscores are all ignored, which 
seems reasonable.

> You could probably come up with rules to reduce possible ambiguity but I
> think the complexity here would outweigh the potential convenience. 
> With the named ranges you describe above I think you would cover most of
> the use cases for shorthand notation like this.

Good point, the single character syntax doesn't seem worth it.

> I understand the problem you're considering here, it occurs in many
> languages that share a common script, but I'm unclear if there's a
> possible solution here. One way to use the above notation might be to
> select different faces within a family for a given Unicode range based
> on which language matches the language of the page.  The default value
> would be 'all' and if the current page language didn't match a language
> in the list, another face would be selected?

More or less yes, although the language might be for a subset of the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael Day | 1 Jun 2009 10:41
Favicon

Re: <at> font-face and unicode-range

> It also includes some rules about matching block names, stating that 
> casting, whitespace, hyphens, and underscores are all ignored, which 
> seems reasonable.

That would be casing, not casting :)

Michael

--

-- 
Print XML with Prince!
http://www.princexml.com
Permalink | Reply | 0 comments |
headers
Håkon Wium Lie | 1 Jun 2009 14:39
Picon
Favicon

RE: [css3-multicol] column-span property

Also sprach Alex Mogilevsky:

 > Column-span prevously allowed values other than '1' and 'all' but
 > it was scaled down because of added complexity of cases where span
 > has more columns than available.

Right. My intention, however, is to scale it back up again in level 4 or something.

 > IMO the property in its current form is unnecessary. All use cases
 > I can think of are covered by either page floats in GCPM or nested
 > multicolumn elements.

How would you express the use case in the spec?:

  h2 { column-span: all }

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome
Permalink | Reply | 3 comments |
headers
Håkon Wium Lie | 1 Jun 2009 15:30
Picon
Favicon

RE: [css3-multicol] page-break-inside and columns

Melinda Grant wrote:

 > > Do you have a preferred list of the values on the break-*
 > > properties that would (a) provide a direct mapping from the
 > > page-* properties and (b) introduce values to influence column
 > > behavior?
 > 
 > For just what we need now, for multicol, we'd suggest:
 > 
 > break-before, -after:
 >         auto | column | page | right | left | avoid | avoid-page 

This gives us:

Current syntax             New syntax                Description

page-break-before: auto    break-before: auto        No forced pb/cb before the element
page-break-before: right   break-before: right       Forced pb so that element ends up on top of right page
page-break-before: left    break-before: left        Forced pb so that element ends up on top of left page
page-break-before: avoid   break-before: avoid       pb/cb avoided before the element
page-break-before: always  break-before: always      pb forced before the element
                           break-before: page        pb forced before the element
                           break-before: column      cb forced before the element
                           break-before: avoid-page  pb avoided before the element

ditto for *-after properties

 > break-inside:
 >         auto | avoid | avoid-page
(Continue reading)

Permalink | Reply | 3 comments |
headers
Håkon Wium Lie | 1 Jun 2009 18:10
Picon
Favicon

RE: [css3-multicol] page-break-inside and columns

I wrote:

 > page-break-before: auto    break-before: auto        No forced pb/cb before the element

   ...

I've added these to a new multicol draft:

  http://dev.w3.org/csswg/css3-multicol/#column-breaks

The values are now symmetrical: you can express all preferences
for pages, columns, and both.

It makes more sense to describe the mappings and the break-*
properties in CSS3-PAGE.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome
Permalink | Reply | 2 comments |
headers
Håkon Wium Lie | 1 Jun 2009 21:31
Picon
Favicon

Re: <at> font-face and unicode-range

Also sprach Michael Day:

 > > This is a good improvement I think but maybe it would be better to just
 > > add a string value to the possible values of <urange>.
 > 
 > That's a good idea. The definitive source for Unicode block names would 
 > be the Blocks.txt file, eg. for Unicode 5.1:
 > 
 > http://unicode.org/Public/UNIDATA/Blocks.txt
 > 
 > It also includes some rules about matching block names, stating that 
 > casing, whitespace, hyphens, and underscores are all ignored, which 
 > seems reasonable.

Using names humanizes the unicode-range descriptor. However, I'd like
to avoid the need for quote marks. The list you refer to is quite
stable, and there's no need for arbitrary additions. So, why not allow these:

  unicode-range: basic-latin;

instead of

  unicode-range: "Basic Latin";

Of course, we want fonts to go beyond basic latin; especially we want
to encourage them to include the letter "å". This could be encoded as:

  unicode-range: basic-latin, latin-extended-a;

which looks long-winded. How about just:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Philip TAYLOR (Ret'd | 1 Jun 2009 21:48
Picon
Favicon

Re: <at> font-face and unicode-range


Håkon Wium Lie wrote:

 > Using names humanizes the unicode-range descriptor. However, I'd like
 > to avoid the need for quote marks. The list you refer to is quite
 > stable, and there's no need for arbitrary additions. So, why not allow these:
 >
 >   unicode-range: basic-latin;
 >
 > instead of
 >
 >   unicode-range: "Basic Latin";

I like the careful use of string quotes here; use
when the string is arbitrary, omit when the set
of strings is fixed.  A convention that HTML could
usefully adopt, IMHO.

Philip Taylo
Permalink | Reply | 0 comments |
headers
Håkon Wium Lie | 1 Jun 2009 23:51
Picon
Favicon

[css3-gcpm] new editor's draft

A new editor's draft of GCPM is available:

  http://dev.w3.org/csswg/css3-gcpm/

This draft tries to distinguish between parts that have two
implementation, or should be within reach for two implementation
within 6 months or so. The other parts, those deemed to be outside of
reach, are marked with a reddish background:

 - functionality that moves elemenst (running elements, 'target-text',
   'target-pull()', named flows)

 - creating paged presentations

 - advanced multicol layout

 - continuation markers

 - change bars

 - line numbers

Also, this draft redefines 'image-resolution' and removes
'background-resolution' as per the minutes from the F2F:

  http://lists.w3.org/Archives/Public/www-style/2009Mar/0065.html

And, the description of the 'text-replace' property has been update.
It is made clear that it only applies to batch processors, and that
text replacements happens after white-space processing. These
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sylvain Galineau | 2 Jun 2009 07:56
Picon
Favicon

[css3-multicol] Pseudo-algorithm feedback

Hi, a few comments on the pseudo-code in section 4.4 [1].

a. I suggest adding line numbers to the code block; it may be very helpful when referring to and commenting
about it. I provide a full copy below.

b. Given that the result of the algorithm may depend on the shrink-to-fit value, should the algorithm to
define this computation be left undefined by CSS ?

c. Line 30 should be :
                     W := available-width;

d. Same for line 41.

e. Section 4.1 indicates that column-width's value may expand to fill the available space. Yet this is not
what the clause from lines 35-38 does. It seems its outcome is only valid 
when the expression matches available-width i.e.

                    (35)  elsif ((column-count * column-width) + ((column-count - 1 ) * column-gap) = available-width) then
...instead of :
                    (35)  elsif ((column-count * column-width) + ((column-count - 1 ) * column-gap) <= available-width) then

(1)   if ((column-width = auto) and (column-count = auto)) or
(2)      ((available-width = unknown) and (column-count = auto)) then
(3)     exit; /* no columns */
(4)   fi
(5)
(6)   if (available-width = unknown) and (column-count != auto) and (column-width != auto) then
(7)     N := column-count;
(8)     W := column-width;
(9)     exit;
(Continue reading)

Permalink | Reply | 1 comment |

Gmane