2:29 p.m.
As I've posted before, I'm using libCSS in an ebook/ePub rendering project
('libEucalyptus'). I've recently come across the need to parse @font-face
rules.
Attached is a patch that does this, following (or attempting to :-) the CSS 3 spec. It
extends the parser to parse font-face rules (which use a slightly different grammar to the
regular CSS, of course...), and adds support to the selection engine to query font-faces
by family name. The support is limited - at the moment it supports 'src:',
'font-family:', 'font-style', and 'font-weight:' rules. It should
be fairly easily extensible to the other font-face directives in the future (unicode-range
etc.).
When parsing, it 'correctly' handles other unsupported directives by ignoring
them. I've tried to keep the font-face handling well compartmentalised into its own
files, although I have extended a couple of the parsing util routines where I thought that
made sense.
On the selection side, for the client, the new css_select_font_faces function will take a
font family name and media and provide a list of font-face results that specify the
font-faces that match. I've deliberately not tried to filter this list further than
by family name and doing some sorting by specificity, so that the user agent can apply its
own logic to the font selection and fallback This logic is - mostly - specified in the
CSS spec, of course, but it's rather vague places, but more importantly also depends
so much on installed fonts and OS capabilities in rendering that I thought it best to
leave it to the client.
I hope the patch meets with approval. Criticism and changes are appreciated, and I'm
very happy to receive constructive feedback (or bug fixes :-). While I am using this in
its current state in a product now, I would very much like to keep my libCSS unforked -
and I hope this will also be useful to others in the future.
Thanks,
Jamie.
2:35 p.m.
Just occurred to me that the previous patch didn't include the new files I'd
created. Let's try that again:
On 1 Dec 2011, at 13:29, James Montgomerie wrote:
As I've posted before, I'm using libCSS in an ebook/ePub
rendering project ('libEucalyptus'). I've recently come across the need to
parse @font-face rules.
Attached is a patch that does this, following (or attempting to :-) the CSS 3 spec. It
extends the parser to parse font-face rules (which use a slightly different grammar to the
regular CSS, of course...), and adds support to the selection engine to query font-faces
by family name. The support is limited - at the moment it supports 'src:',
'font-family:', 'font-style', and 'font-weight:' rules. It should
be fairly easily extensible to the other font-face directives in the future (unicode-range
etc.).
When parsing, it 'correctly' handles other unsupported directives by ignoring
them. I've tried to keep the font-face handling well compartmentalised into its own
files, although I have extended a couple of the parsing util routines where I thought that
made sense.
On the selection side, for the client, the new css_select_font_faces function will take a
font family name and media and provide a list of font-face results that specify the
font-faces that match. I've deliberately not tried to filter this list further than
by family name and doing some sorting by specificity, so that the user agent can apply its
own logic to the font selection and fallback This logic is - mostly - specified in the
CSS spec, of course, but it's rather vague places, but more importantly also depends
so much on installed fonts and OS capabilities in rendering that I thought it best to
leave it to the client.
I hope the patch meets with approval. Criticism and changes are appreciated, and I'm
very happy to receive constructive feedback (or bug fixes :-). While I am using this in
its current state in a product now, I would very much like to keep my libCSS unforked -
and I hope this will also be useful to others in the future.
Thanks,
Jamie.
11:49 p.m.
On 1 Dec 2011, at 13:29, James Montgomerie wrote:
> As I've posted before, I'm using libCSS in an ebook/ePub rendering
project ('libEucalyptus'). I've recently come across the need to parse
@font-face rules.
>
> Attached is a patch that does this, following (or attempting to :-)
the CSS 3 spec. It extends the parser to parse font-face rules (which
use a slightly different grammar to the regular CSS, of course...),
and adds support to the selection engine to query font-faces by family
name. The support is limited - at the moment it supports 'src:',
'font-family:', 'font-style', and 'font-weight:' rules. It
should be
fairly easily extensible to the other font-face directives in the
future (unicode-range etc.).
Excellent!
> When parsing, it 'correctly' handles other unsupported
directives by
ignoring them. I've tried to keep the font-face handling well
compartmentalised into its own files, although I have extended a
couple of the parsing util routines where I thought that made sense.
Sounds fine to me.
> On the selection side, for the client, the new
css_select_font_faces
function will take a font family name and media and provide a list of
font-face results that specify the font-faces that match. I've
deliberately not tried to filter this list further than by family name
and doing some sorting by specificity, so that the user agent can
apply its own logic to the font selection and fallback This logic is
- mostly - specified in the CSS spec, of course, but it's rather vague
places, but more importantly also depends so much on installed fonts
and OS capabilities in rendering that I thought it best to leave it to
the client.
Yeah; that matches what we did with font-families, so I've no objection
to this approach. After all, the client is the only place that is
capable of making a fully informed decision here :)
> I hope the patch meets with approval. Criticism and changes
are
appreciated, and I'm very happy to receive constructive feedback (or
bug fixes :-). While I am using this in its current state in a
product now, I would very much like to keep my libCSS unforked - and I
hope this will also be useful to others in the future.
I've had a relatively quick look through it. It appears mostly fine, but
it's been a while since I last looked at the CSS3 Fonts module. I'll
endeavour to give it a proper look at the weekend.
Cheers,
J.
10:09 p.m.
On Thu, 2011-12-01 at 22:49 +0000, John-Mark Bell wrote:
I've had a relatively quick look through it. It appears mostly
fine, but
it's been a while since I last looked at the CSS3 Fonts module. I'll
endeavour to give it a proper look at the weekend.
Ok. I've been through it and committed it as r13244.
Mostly, it involved code style cleanups, a bunch of fixes for the parser
to make it match the spec better[1], and some memory leak fixes.
WRT:
/* It seems a little weird to me that the standard specifies
* that the format is a comma seperated list. How can a font at
* a specific location have more than one fomat? [JRM].
*/
If fetched over HTTP, content negotiation can result in multiple formats
being hosted at the same URL.
Thanks,
J.
1. By my reading of the grammar, it's never permissible to follow
local(foo) with a format(...) specifier
7:27 p.m.
On 4 Dec 2011, at 21:09, John-Mark Bell wrote:
On Thu, 2011-12-01 at 22:49 +0000, John-Mark Bell wrote:
> I've had a relatively quick look through it. It appears mostly fine, but
> it's been a while since I last looked at the CSS3 Fonts module. I'll
> endeavour to give it a proper look at the weekend.
Ok. I've been through it and committed it as r13244.
Mostly, it involved code style cleanups, a bunch of fixes for the parser
to make it match the spec better[1], and some memory leak fixes.
Thanks. I've looked through the diffs to my original code, they all look good to me.
I really appreciate the time you put into this.
WRT:
/* It seems a little weird to me that the standard specifies
* that the format is a comma seperated list. How can a font at
* a specific location have more than one fomat? [JRM].
*/
If fetched over HTTP, content negotiation can result in multiple formats
being hosted at the same URL.
Ah, I guess that makes sense. In my head, a font of a different format would be a
different 'resource' (especially in my world of ebooks where they're a file on
disk), but I guess that's not really the case if they're the same design.
Although, are user-agents expected to only accept the font formats they can display when
making e.g. an HTTP request for the font? I suspect many won't...
Again, thanks for taking the patch. I'm enjoying using and working with libCSS,
it's a great piece of work.
Jamie.
4123
days inactive
4128
days old
netsurf-dev@netsurf-browser.org
4 comments
2 participants
participants (2)
-
James Montgomerie -
John-Mark Bell