Portet NetSurf to SH4 CPU
by o.gruber＠nit.at
Hi
I have wroten a Receiver System like Enigma2.
The Name of the project ist titan (http://www.youtube.com/watch?v=0vyGTwi8GT0)
Now i have portet Netsurf to SH4 CPU STM Linux.
The porting process was going without any problems.
I have then added hardware spezial framebuffer and keyinput code to linux.c (needed 1 day).
The browser now runs (without problems <- i hope :) ).
Your project is very cool, and i have saved many many many times to code a own browser.
In the next step i will add video play function. On the receiver i have programms who can handle the most
videoformat and nees only the url to play it.
If you have a tip, in wich function i can call this external binary, feel free to wrote me this.
thanks
NIT
11 years, 11 months
Re: RUfl font substitution
by W P Blatchley
On Thu, 08 Dec 2011 13:00:15 +0100,
<netsurf-dev-request(a)netsurf-browser.org> wrote:
>> > Is the font chosen just the first one RUfl encounters
>> > (alphabetically?) that has a match?
>>
>> Pretty much, yes. See:
>> http://source.netsurf-browser.org/trunk/rufl/src/rufl_init.c?revision=979...
> Just to explain the motivation behind this design: the substitution
> table is 65K, and there are 18 weight-slant combinations. I wanted
> RUfl to have small memory usage, so adding a table for each weight-
> slant would have taken too much space. Perhaps a different data
> structure or approach would be possible.
> It wouldn't be difficult to construct the table in a different order
> from alphabetical though.
> James
Thanks for the additional background information, James. Certainly 18 x
65k would be a bit heavy!
I couple of thoughts occur:
- RUfl could pick the most "neutral"-styled font (no slant, medium weight)
it can find when there are multiple options for a point in the
substitution table. Ideally, it would be a bit intelligent about it, and
favour choosing fonts it had already used in the table, to avoid a
mish-mash of fonts creeping in.
- Although 18 tables would probably be overkill, three (65,536 * 3 =~ 197k
) might be a compromise between memory footprint and aesthetics: One for
"no-style", one for "average italics" and one for "average bold"?
- In my case, I have a font family with about 7 different weights (no
slants) all defining the same glyphs, one of which RUfl is using for the
majority of points in the substitution table. If RUfl could be aware of
"equal" fonts - fonts in the same family that define exactly the same
subset of glyphs, just in varying styles - it could match the weight/slant
as a second step after looking up the codepoint in the (still 65k)
substitution table. Of course, that would only be of help when the user
has families of fonts defining the same glyphs, as described, but that's
probably not all that infrequent.
- Is the substitution table statically linked to each binary that uses
RUfl? I guess it must be. If the substitution table were to grow much in
size, and as more and more software starts to use RUfl (as I hope will be
the case), there's perhaps an argument for moving it into a module and
only maintaining a single set of tables for all apps? In fact, the best
thing would be if it could hook into the Font Manager and provide its
functionality to all apps "for free". Unfortunately, as I've recently
discovered, FontV isn't actually implemented in any version of RISC OS.
But the Font Manager itself could be modified. I'm not sure what the deal
is with modules that take 10 minutes or so to start up, though (as could
be the case when RUfl indexes fonts)!
To be clear - I'm certainly not expecting anyone to do anything about this
(i.e. coding); I'm just interested in discussing options here. If a
suitable consensus of opinion emerges, I'd be happy to look at making a
patch/patches when I have a bit more time.
Thanks,
WPB
11 years, 11 months
Re: RUfl font substitution
by W P Blatchley
On Mon, 05 Dec 2011 13:00:17 +0100,
<netsurf-dev-request(a)netsurf-browser.org> wrote:
> No, it doesn't. It *will* match styles/weight when selecting the
> appropriate initial font, but the substitution table is built without
> paying attention to this information. As RISC OS fonts carry little
> metadata about styles/weights, RUfl simply uses the font name as a
> guide.
I don't quite follow this. What do you mean by "initial font" here? Sorry
if I'm being slow!
So, the substitution table is just a single mapping of UCS code point ->
one (of a possible many) fonts that contain a glyph for that code point?
Is the font chosen just the first one RUfl encounters (alphabetically?)
that has a match?
And what does RUfl take as hints to the font style from the name?
".Medium" and ".Bold", that kind of thing?
Many thanks,
WPB
11 years, 11 months
[PATCH] LibCSS: @font-face
by James Montgomerie
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 years, 12 months
Re: RUfl font substitution
by W P Blatchley
On Tue, 06 Dec 2011 13:00:21 +0100,
<netsurf-dev-request(a)netsurf-browser.org> wrote:
>> So, the substitution table is just a single mapping of UCS code point ->
>> one (of a possible many) fonts that contain a glyph for that code point?
> That's what I wrote, yes.
Sorry if what I wrote seemed redundant. I find paraphrasing a useful way
of confirming that I have indeed understood what I thought I had!
>> Is the font chosen just the first one RUfl encounters (alphabetically?)
>> that has a match?
> Pretty much, yes. See:
> http://source.netsurf-browser.org/trunk/rufl/src/rufl_init.c?revision=979...
>
>> And what does RUfl take as hints to the font style from the name?
>> ".Medium" and ".Bold", that kind of thing?
> Yes.
> See:
> http://source.netsurf-browser.org/trunk/rufl/src/rufl_init.c?revision=979...
Many thanks for these pointers- very helpful.
> Patches to improve the situation are always welcome.
I would very much like to contribute to RUfl. I hope I'll find the time in
the future.
Thanks,
WPB
11 years, 12 months
RUfl font substitution
by W P Blatchley
Now I've expanded the repertoire of UCS fonts on my system, I'm wondering
how RUfl decides from which fonts to take glyphs for substituting when
they're not present in the font being painted with. Could someone explain,
please? Is any attempt made to match styles and weights, and if so, how
does RUfl determine the style and weight of a font?
TIA, WPB
11 years, 12 months
[PATCH] libCSS: Fix bug with cascading font-family if no system font is specified in the list
by James Montgomerie
Hello again,
I've noticed a bug today in the cascading of font-family names. It's not related to yesterday's @font-face patch - it's in existing code.
CSS that causes the problems to exhibit is like this:
p.name {
font-family: "Minion Pro";
}
Note that there's no fallback system font specified as would be usual.
The client-visible symptom is that, with CSS like this, the list of font names returned by css_computed_font_family is always empty rather than containing the specified font name.
The cause is that, in css__compose_font_family, the child's font-family list contains the correctly parsed font names, but the type, because no system font was specified, is still CSS_FONT_FAMILY_INHERIT. This causes the font list to be overwritten with the parent's list.
The spec (CSS 2 and 3) doesn't seem to say specifically what should happen if there's no system font specified. Existing browsers seem to fall back on the browser default font as a last resort (so not the parent's font, which might also make sense).
I've fixed the problem by following their lead; in css__cascade_font_family, if there are specific fonts used, I call ua_default_for_property and use the system font it returns as the system font value instead of leaving CSS_FONT_FAMILY_INHERIT.
I also took the opportunity to clean up css__compose_font_family a bit - the local variable naming in it referred to URLs when it's really using font family name strings, not URLs.
Patch attached.
Jamie.
11 years, 12 months
double const in nsurl.h
by François Revol
I just tried a BeOS build and it fails due to gcc 2.95 complaining about
a double const at line 63 in nsurl.h
There is a const char const * argument there.
I don't think it's intentional, right ?
François.
11 years, 12 months
