SVG support

Hi all,

Using Dev Cl #6508 RISC OS 5.28

- For some reason Netsurf renders SVGs scaled by a factor of 70%ish in the
Y direction. Or, I suppose, 140%ish in the X direction.

* For example, go to www.free-svg.org choose an SVG and click
"Download SVG" to display it in the Netsurf window.

- Resizing the browser window re-renders the SVG over the top of the old
one

- is it possible to render at 100% in both X and Y directions and if
possible to clear the page before replotting the graphic?

- And incidentally it might be nice to launch a browser window on double
clicking a SVG file. Can one of you clever folks write an Obey file?

Thanks

--
--
AVAILABLE NOW - Graphics Tablets for RISC OS - buy from www.dragdrop.co.uk

Chris Dewhurst, Editor, Drag N Drop for RISC OS
editor@dragdrop.co.uk www.dragdrop.co.uk
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

[gccsdk] GCC internal compiler error *** buffer overflow detected ***

Hi,

This is a bug report for GCC with a preprocessed C source file attached.
I have been attempting to use GCCSDK GCC 4.7.4 Release 6, installed and
updated by svn, on an x86_64 build of Linux Mint XFCE with kernel
5.15.0-84-generic #93-Ubuntu SMP Tue Sep 5 17:16:10 UTC 2023.

gccsdk/cross/bin/arm-unknown-riscos-gcc consistently aborts when compiling
a specific C source file with the following lines output:

*** buffer overflow detected ***: terminated
libavdevice/avdevice.c: In function 'avdevice_version':
libavdevice/avdevice.c:68:1: internal compiler error: Aborted

In the attached zip archive is the single preprocessed source file
"avdevice_preprocessed.c" and a sequence of shell commands and outputs
which I hope will provide sufficient contextual information to reproduce
the problem. The original source of the shell commands is a set of
makefiles created by an autoconf-created configure script. Feel free to
contact me for more information.
--
Regards,
Christopher Martin

Re: TV guide disappears on upgrade to latest Netsurf

On 5 Sep 2023 as I do recall,
Harriet Bazley wrote:

> I upgraded to Dev CL #5442 from #5438, and the TVGuide.co.uk site became
> almost unusable as a result -
> https://www.tvguide.co.uk/mobile/?systemid=3 now gets automatically
> redirected to the unreadable https://www.tvguide.co.uk/freeview

[snip]


> (And if you can identify the distorted channel logos at the left-hand
> edge, you can click on each one individually to see a complete schedule
> for the day on a larger scale then before, e.g.
> https://www.tvguide.co.uk/channel/fd66055a-5bc7-51e8-8421-df88e60c98b3/channel-4/1
Even more frustratingly, clicking on the BBC2 logo now produces a blank
page
https://www.tvguide.co.uk/channel/0b6789ff-d68b-5b85-8412-8f11d5e22e10/bbc-two-england/0
even though all the others appear to work...


--
Harriet Bazley == Loyaulte me lie ==

Old Programmers never die. They just terminate and stay resident
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

libcss fill- and stroke-opacity

As promised, here's my libcss branch adding the SVG fill- and
stroke-opacity properties. HTTPS also works but the cert is
self-signed pending a new release of apache; its SHA1 fingerprint is
C8:01:8B:A6:3A:07:C0:65:AF:F0:CB:17:5F:A3:B5:9F:5B:D0:FC:E0.

http://gitweb.michael.orlitzky.com/libcss.git fill-stroke-opacity

Here's a summary of the changes. The commits are probably a bit too
fine-grained but it makes them easy to reorder and amend. I did my
best to keep the test suite passing for as long as possible.


Michael Orlitzky (40):
docs/Bytecode: document the forthcoming fill-opacity
include/libcss/properties.h: define fill-opacity enumeration
src/bytecode/opcodes.h: define fill-opacity enumeration
src/parse/properties/properties.h: add fill-opacity prototype
include/libcss/computed.h: add fill-opacity prototype
src/select/select_config.py: add fill-opacity
src/select: regenerate autogenerated_*.h for fill-opacity
src/select/properties: add fill-opacity implementation
src/select/properties/properties.h: declare fill-opacity functions
src/select/dispatch.c: add fill-opacity functions to the table
src/parse/propstrings.{c,h}: support fill-opacity
include/libcss/properties.h: define CSS_PROP_FILL_OPACITY
src/parse/properties: add fill-opacity implementation
src/parse/important.c: handle CSS_PROP_FILL_OPACITY
src/parse/properties/properties.{c,h}: add fill-opacity unit mask
src/select/computed.c: implement the computed fill-opacity
src/parse/properties/properties.c: add fill-opacity property handler
test/dump{,_computed}.h: dump fill-opacity
test/data: add expected fill-opacity values
test/data/parse2: add SVG property test suite
docs/Bytecode: document the forthcoming stroke-opacity
include/libcss/properties.h: define stroke-opacity enumeration
src/bytecode/opcodes.h: define stroke-opacity enumeration
src/parse/properties/properties.h: add stroke-opacity prototype
include/libcss/computed.h: add stroke-opacity prototype
src/select/select_config.py: add stroke-opacity
src/select: regenerate autogenerated_*.h for stroke-opacity
src/select/properties: add stroke-opacity implementation
src/select/properties/properties.h: declare stroke-opacity functions
src/select/dispatch.c: add stroke-opacity functions to the table
src/parse/propstrings.{c,h}: support stroke-opacity
include/libcss/properties.h: define CSS_PROP_STROKE_OPACITY
src/parse/properties: add stroke-opacity implementation
src/parse/important.c: handle CSS_PROP_STROKE_OPACITY
src/parse/properties/properties.{c,h}: add stroke-opacity unit mask
src/select/computed.c: implement the computed stroke-opacity
src/parse/properties/properties.c: add stroke-opacity property handler
test/dump{,_computed}.h: dump stroke-opacity
test/data: add expected stroke-opacity values
test/data/parse2: add SVG stroke-opacity property tests

docs/Bytecode | 20 +++++++++-
include/libcss/computed.h | 8 ++++
include/libcss/properties.h | 12 ++++++
src/bytecode/opcodes.h | 9 +++++
src/parse/important.c | 10 +++++
src/parse/properties/Makefile | 2 +
src/parse/properties/fill_opacity.c | 82 +++++++++++++++++++++++++++++++++++++++++
src/parse/properties/properties.c | 4 ++
src/parse/properties/properties.h | 8 ++++
src/parse/properties/stroke_opacity.c | 82 +++++++++++++++++++++++++++++++++++++++++
src/parse/propstrings.c | 2 +
src/parse/propstrings.h | 33 +++++++++--------
src/select/autogenerated_computed.h | 20 ++++++----
src/select/autogenerated_propget.h | 106 +++++++++++++++++++++++++++++++++++++++++------------
src/select/autogenerated_propset.h | 88 ++++++++++++++++++++++++++++++++------------
src/select/computed.c | 12 ++++++
src/select/dispatch.c | 8 ++++
src/select/properties/Makefile | 2 +
src/select/properties/fill_opacity.c | 73 ++++++++++++++++++++++++++++++++++++
src/select/properties/properties.h | 2 +
src/select/properties/stroke_opacity.c | 73 ++++++++++++++++++++++++++++++++++++
src/select/select_config.py | 2 +
test/data/parse2/INDEX | 1 +
test/data/parse2/svg.dat | 79 +++++++++++++++++++++++++++++++++++++++
test/data/select/defaulting.dat | 26 +++++++++++++
test/data/select/tests1.dat | 254 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
test/dump.h | 24 ++++++++++++
test/dump_computed.h | 48 ++++++++++++++++++++++++
28 files changed, 1019 insertions(+), 71 deletions(-)
create mode 100644 src/parse/properties/fill_opacity.c
create mode 100644 src/parse/properties/stroke_opacity.c
create mode 100644 src/select/properties/fill_opacity.c
create mode 100644 src/select/properties/stroke_opacity.c
create mode 100644 test/data/parse2/svg.dat
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH] src/select/Makefile: the select_generator target is PHONY

On Mon, 18 Sept 2023 at 15:25, Michael Orlitzky <michael@orlitzky.com> wrote:

> +.PHONY: select_generator

Applied, thanks!
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH] src/select/Makefile: the select_generator target is PHONY

This target doesn't create an object named "select_generator", so it
can be marked .PHONY to improve performance slightly and to avoid a
conflict with files/directories of the same name.
---
src/select/Makefile | 1 +
1 file changed, 1 insertion(+)

diff --git a/src/select/Makefile b/src/select/Makefile
index b9e7390..e237d46 100644
--- a/src/select/Makefile
+++ b/src/select/Makefile
@@ -1,4 +1,5 @@
# Sources
+.PHONY: select_generator
select_generator:
python3 src/select/select_generator.py

--
2.41.0
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: CSS support in libsvgtiny

On 17/09/2023 22:18, Michael Orlitzky wrote:

> On 2023-09-17 20:50:42, Michael Drake wrote:
>> For what it's worth, I'm happy for anything of mine in that area to be
>> relicensed as MIT.
>>
> Good to know! I tried to track down the origins of the selection
> handlers, but it looks like most of them go back to,
>
> commit ddeadd1c02880367ad786b113d352a519f45ec73
> Author: John Mark Bell <jmb@netsurf-browser.org>
> Date: Thu Jul 23 23:05:34 2009 +0000
>
> Merge LibCSS port to trunk.
>
> svn path=/trunk/netsurf/; revision=8752
>
> where the trail goes cold.

Yes -- they didn't exist before then (as libcss didn't either -- at
least not as far as NetSurf is concerned!)

> It just occurred to me, though, that if the
> selection handlers are factored out into a separate library, that
> there would be no problem with licensing that library under the GPLv2
> and then linking to it.

If it's only myself and Michael, then I doubt there's a problem (like
Michael, I've no objection for any of my code in this area being
relicensed). What I haven't done, at least, is looked to see who else
might have changed this stuff!


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: CSS support in libsvgtiny

On 2023-09-17 20:50:42, Michael Drake wrote:
>
> For what it's worth, I'm happy for anything of mine in that area to be
> relicensed as MIT.
>

Good to know! I tried to track down the origins of the selection
handlers, but it looks like most of them go back to,

commit ddeadd1c02880367ad786b113d352a519f45ec73
Author: John Mark Bell <jmb@netsurf-browser.org>
Date: Thu Jul 23 23:05:34 2009 +0000

Merge LibCSS port to trunk.

svn path=/trunk/netsurf/; revision=8752

where the trail goes cold. It just occurred to me, though, that if the
selection handlers are factored out into a separate library, that
there would be no problem with licensing that library under the GPLv2
and then linking to it.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: CSS support in libsvgtiny

On Sun, 17 Sept 2023 at 15:18, John-Mark Bell <jmb@netsurf-browser.org> wrote:
> On 14/09/2023 14:43, Michael Drake wrote:

> > I agree, it would be better to have a shared implementation of the
> > LibCSS/LibDOM integration. Either as a LibDOM-CSS or maybe as
> > an optional LibDOM binding for LibCSS, a bit like LibDOM has
> > the Hubbub/LibXML bindings. What do you think John-Mark?
>
> I have no strong view, other than to observe that the code in NetSurf
> itself is licensed under GPLv2, and not MIT/Expat (as used by most of
> the libraries), so simply copying it probably isn't the right answer. I
> don't recall who has contributed to that code, but any relicensing
> thereof would need their permission.

True.

For what it's worth, I'm happy for anything of mine in that area to be
relicensed as MIT.

Cheers,
Michael
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/2] libdom: fix two more libxml parser segfaults

On Sun, 17 Sept 2023 at 15:58, Michael Orlitzky <michael@orlitzky.com> wrote:

> I've also submitted a patch for a libcss segfault that is probably
> causing a lot of netsurf crashes at,
>
> https://bugs.netsurf-browser.org/mantis/view.php?id=2854

Nice patch. Applied!

Thanks,
Michael
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: CSS support in libsvgtiny

On 2023-09-17 15:17:57, John-Mark Bell wrote:
> >
> > I agree, it would be better to have a shared implementation of the
> > LibCSS/LibDOM integration. Either as a LibDOM-CSS or maybe as
> > an optional LibDOM binding for LibCSS, a bit like LibDOM has
> > the Hubbub/LibXML bindings. What do you think John-Mark?
>
> I have no strong view, other than to observe that the code in NetSurf
> itself is licensed under GPLv2, and not MIT/Expat (as used by most of
> the libraries), so simply copying it probably isn't the right answer. I
> don't recall who has contributed to that code, but any relicensing
> thereof would need their permission.

Ah, thanks, I hadn't noticed the license mismatch. That's a little
annoying, but I guess it's not the immediate problem. I've got enough
to keep me busy between cleaning up the opacity patches, adding tests,
and trying to discern how the more complicated properties are parsed.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/2] libdom: fix two more libxml parser segfaults

On 17/09/2023 15:58, Michael Orlitzky wrote:

> While I have your attention and whereas no good deed goes unpunished,
> I've also submitted a patch for a libcss segfault that is probably
> causing a lot of netsurf crashes at,
>
> https://bugs.netsurf-browser.org/mantis/view.php?id=2854
>
> Thanks :)

Michael -- can you investigate this one, please? (I think you
implemented the style reversion stuff, correct?)


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/2] libdom: fix two more libxml parser segfaults

While I have your attention and whereas no good deed goes unpunished,
I've also submitted a patch for a libcss segfault that is probably
causing a lot of netsurf crashes at,

https://bugs.netsurf-browser.org/mantis/view.php?id=2854

Thanks :)
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH] makefiles/Makefile.top: dependencies for PRE_ and POST_TARGETS

On 2023-09-17 15:08:33, John-Mark Bell wrote:
>
> Merged, thank you. I moved where these additional rules are declared and
> made them conditional on there being any PRE/POST_TARGETS, but it should
> be semantically equivalent to what you had.
>

Again, thanks.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/2] libdom: fix two more libxml parser segfaults

On 2023-09-17 14:52:25, John-Mark Bell wrote:
>
> Thanks for these. I have not applied them, however, as the underlying
> causes were failure to deal with a) errors within the libxml SAX
> handlers and b) within the node addition logic. In either case, there is
> no reasonable recovery path, so the parser should bail out, rather than
> carrying on with undefined state. I've just pushed two changes to thie
> binding that do this, and the libsvgtiny testsuite now passes happily
> with libdom using libxml as its parser.
>

Ok, fine by me, thank you!
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: CSS support in libsvgtiny

On 14/09/2023 14:43, Michael Drake wrote:
> Hi Michael,
>
> On Tue, 12 Sept 2023 at 23:45, Michael Orlitzky <michael@orlitzky.com> wrote:
>
>> I dumped the new properties into the default level, but this raises
>> a question: should libcss use a different CSS level for SVG?
>
> Good question. What do you think John-Mark?

I'm not sure it's necessary -- libcss will simply expose any and all
properties it knows about (and apply the cascade as appropriate).
However, it is not responsible for applying the resulting computed
styles to the document -- that is up to the client. A non-SVG-aware
client would never look at them and thus would be none the wiser as to
their existence. Obviously an SVG-aware client would look at them.

The only potentially difficult case would be an SVG-aware client that is
applying CSS to something that isn't an SVG. However, the client itself
would have to deal with that by ensuring it ignored these properties
when the document it's dealing with is not an SVG.

>>
>> 3. I copied the css_select_handler and css_unit_ctx from netsurf into
>> svgtiny.c. Thankfully, I didn't have to think about the unit
>> conversions at all because opacity is a float. The select handler
>> callbacks were tedious, but most of them can be copied from netsurf
>> with minimal changes, fudging interned string names and replacing
>> html-only function calls. I wound up copying the user data handler
>> too. Who knows if any of this stuff works, but it hasn't crashed.
>>
>> Ultimately, since netsurf uses libsvgtiny, copy-pasting the select
>> handler wouldn't be a great solution. I think it would make sense
>> to factor out the libdom/libcss integration into something like a
>> libdom-css that provides a generic css_select_handler
>> implementation.
>
> I agree, it would be better to have a shared implementation of the
> LibCSS/LibDOM integration. Either as a LibDOM-CSS or maybe as
> an optional LibDOM binding for LibCSS, a bit like LibDOM has
> the Hubbub/LibXML bindings. What do you think John-Mark?

I have no strong view, other than to observe that the code in NetSurf
itself is licensed under GPLv2, and not MIT/Expat (as used by most of
the libraries), so simply copying it probably isn't the right answer. I
don't recall who has contributed to that code, but any relicensing
thereof would need their permission.

Note also that, as with the SVG-specific properties, the expectation was
always that various parts of the selection handler would have to be
document-format aware (e.g. extracting the presentational hints from an
HTML document is not something that would be wanted when processing some
other document format).


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH] makefiles/Makefile.top: dependencies for PRE_ and POST_TARGETS

On 14/08/2023 18:23, Michael Orlitzky wrote:
> The PRE_TARGETS and POST_TARGETS are supposed to be built before and
> after $(OBJECTS), respectively -- at least according to the comments
> in Makefile.top:

[...]

Merged, thank you. I moved where these additional rules are declared and
made them conditional on there being any PRE/POST_TARGETS, but it should
be semantically equivalent to what you had.


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH 0/2] libdom: fix two more libxml parser segfaults

On 12/08/2023 03:45, Michael Orlitzky wrote:
> The libsvgtiny test suite exposes two segfaults in libdom's libxml2
> parser. The first I'm somewhat confident in: linking dom/xml nodes
> can fail (or never happen), and if we encounter an unlinked node,
> something is wrong. Reasonable enough.
>
> The second was easy to fix, but I'm not as sure that the fix is
> correct. There's a branch where we jump to parent->children if we
> can't find an earlier element node, and in at least one case, there
> are no such children. Should there be? Adding a NULL check avoids a
> segfault, but maybe we should notice the problem sooner.

Thanks for these. I have not applied them, however, as the underlying
causes were failure to deal with a) errors within the libxml SAX
handlers and b) within the node addition logic. In either case, there is
no reasonable recovery path, so the parser should bail out, rather than
carrying on with undefined state. I've just pushed two changes to thie
binding that do this, and the libsvgtiny testsuite now passes happily
with libdom using libxml as its parser.


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: [PATCH] makefiles: support building shared libs on Darwin

On 01/07/2023 04:50, Caleb Xu wrote:
> On Darwin (macOS), the flags needed to create a shared
> library are different. Moreover, the extension is .dylib
> and the version portion of the soname is inserted between
> the library name and the libext, e.g. lifoo.1.2.3.dylib.

Applied. Thank you.


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: "error: ‘t.data.character.ptr’ may be used uninitialized " when building hubbub with gcc 11

On 27/05/2023 08:32, Andy Tai wrote:
> patch to get rid of the warning:
>

Thank you for the report. I have pushed a fix (it needed to copy the
contents of the token it was processing first).


John-Mark.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: CSS support in libsvgtiny

Hi Michael,

On Tue, 12 Sept 2023 at 23:45, Michael Orlitzky <michael@orlitzky.com> wrote:

> tl;dr has anyone tried to use libcss to add CSS support to libsvgtiny?

Not to my knowledge. It's definitely something that's worth doing.

> 1. First, I chose to implement the fill-opacity and stroke-opacity
> properties because they're easy. They have the same form as the
> usual CSS "opacity" property. To implement them, I basically
> git grep'd for "opacity" in libcss and copy/pasted everything to
> fill-opacity and stroke-opacity. It was tedious, but otherwise
> not difficult because opacity is easy to parse.
>
> Handling the more complicated properties or factoring out the
> shared implementations of opacity, fill-opacity, and stroke-opacity
> would likely require someone who knows libcss better.

That's fine.

> I dumped the new properties into the default level, but this raises
> a question: should libcss use a different CSS level for SVG?

Good question. What do you think John-Mark?

> 2. In libsvgtiny, I added a libcss context to the parser state, and
> then taught the SVG parser to parse a <style> element into a sheet,
> and append the sheet to said context. This part is just boilerplate.
> The build system needs to be updated to build/link against libcss.
>
> 3. I copied the css_select_handler and css_unit_ctx from netsurf into
> svgtiny.c. Thankfully, I didn't have to think about the unit
> conversions at all because opacity is a float. The select handler
> callbacks were tedious, but most of them can be copied from netsurf
> with minimal changes, fudging interned string names and replacing
> html-only function calls. I wound up copying the user data handler
> too. Who knows if any of this stuff works, but it hasn't crashed.
>
> Ultimately, since netsurf uses libsvgtiny, copy-pasting the select
> handler wouldn't be a great solution. I think it would make sense
> to factor out the libdom/libcss integration into something like a
> libdom-css that provides a generic css_select_handler
> implementation.

I agree, it would be better to have a shared implementation of the
LibCSS/LibDOM integration. Either as a LibDOM-CSS or maybe as
an optional LibDOM binding for LibCSS, a bit like LibDOM has
the Hubbub/LibXML bindings. What do you think John-Mark?

> 4. I added fill_opacity and stroke_opacity members to the SVG parser
> context.
>
> 5. I taught svgtiny_parse_paint_attributes() how to find the computed
> fill- and stroke-opacities. We're already parsing the inline style
> so that part is pretty easy. Once we have them, they can be set in
> the context. Disclaimer: I skipped composition with the parent
> style to save time, but that could probably be copied from netsurf
> too.

Composition is mostly to handle inherit. If those properties aren't
inherited, it won't make a difference at the moment.

> There's a problem here: the SVG parser makes one pass through the
> file, using a big struct to keep track of the current color, stroke
> width, et cetera, as we create and append shapes to the resulting
> abstract representation. If a <style> element appears at the end of
> the SVG, its rules won't affect the shapes created earlier. (This
> isn't a huge problem, it's just worth noting that I half-assed this
> part to get the thing working.)
>
> 6. You can now render each shape with the fill_opacity and
> stroke_opacity from the context.

Cool!

> Now I can say I wasn't lying when I thought "I could probably do
> that." Of course I skipped over the boring/hard parts, but when all is
> said and done, the framework can be put in place without too much
> extra code.
>
> Does it make sense for libsvgtiny?

Yeah, certainly!

Best regards,
Michael
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

ci.netsurf-browser.org unavailable?

ci.netsurf-browser.org seems to be unreachable right now.

David
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

CSS support in libsvgtiny

tl;dr has anyone tried to use libcss to add CSS support to libsvgtiny?

I have a small project that renders GTK icons using libsvgtiny. Its
main missing feature is that it can't handle GTK's "symbolic" SVGs,
which are basically just regular SVGs wrapped in an include with a
<style> element at the top. The styles themselves are trivial,
consisting of only a few !important color changes.

That got me wondering about CSS support in libsvgtiny. I could
probably hack in special cases for the exact <style> elements I need
(they're hard-coded in GTK), but it would be a lot more elegant -- and
fix a bunch of existing rendering bugs -- if CSS were supported
properly. To that end, I wrote a very ugly proof-of-concept that
handles the SVG fill-opacity and stroke-opacity properties:

1. First, I chose to implement the fill-opacity and stroke-opacity
properties because they're easy. They have the same form as the
usual CSS "opacity" property. To implement them, I basically
git grep'd for "opacity" in libcss and copy/pasted everything to
fill-opacity and stroke-opacity. It was tedious, but otherwise
not difficult because opacity is easy to parse.

Handling the more complicated properties or factoring out the
shared implementations of opacity, fill-opacity, and stroke-opacity
would likely require someone who knows libcss better.

I dumped the new properties into the default level, but this raises
a question: should libcss use a different CSS level for SVG?

2. In libsvgtiny, I added a libcss context to the parser state, and
then taught the SVG parser to parse a <style> element into a sheet,
and append the sheet to said context. This part is just boilerplate.
The build system needs to be updated to build/link against libcss.

3. I copied the css_select_handler and css_unit_ctx from netsurf into
svgtiny.c. Thankfully, I didn't have to think about the unit
conversions at all because opacity is a float. The select handler
callbacks were tedious, but most of them can be copied from netsurf
with minimal changes, fudging interned string names and replacing
html-only function calls. I wound up copying the user data handler
too. Who knows if any of this stuff works, but it hasn't crashed.

Ultimately, since netsurf uses libsvgtiny, copy-pasting the select
handler wouldn't be a great solution. I think it would make sense
to factor out the libdom/libcss integration into something like a
libdom-css that provides a generic css_select_handler
implementation.

4. I added fill_opacity and stroke_opacity members to the SVG parser
context.

5. I taught svgtiny_parse_paint_attributes() how to find the computed
fill- and stroke-opacities. We're already parsing the inline style
so that part is pretty easy. Once we have them, they can be set in
the context. Disclaimer: I skipped composition with the parent
style to save time, but that could probably be copied from netsurf
too.

There's a problem here: the SVG parser makes one pass through the
file, using a big struct to keep track of the current color, stroke
width, et cetera, as we create and append shapes to the resulting
abstract representation. If a <style> element appears at the end of
the SVG, its rules won't affect the shapes created earlier. (This
isn't a huge problem, it's just worth noting that I half-assed this
part to get the thing working.)

6. You can now render each shape with the fill_opacity and
stroke_opacity from the context.


Now I can say I wasn't lying when I thought "I could probably do
that." Of course I skipped over the boring/hard parts, but when all is
said and done, the framework can be put in place without too much
extra code.

Has anyone tried this before? Does it make sense for libsvgtiny?
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

TV guide disappears on upgrade to latest Netsurf

I upgraded to Dev CL #5442 from #5438, and the TVGuide.co.uk site became
almost unusable as a result -
https://www.tvguide.co.uk/mobile/?systemid=3 now gets automatically
redirected to the unreadable https://www.tvguide.co.uk/freeview

(I switched back to #5438 and found that I could still access the same
pages as before, so I don't know if something has changed about the way
that NetSurf identifies itself - I had JavaScript disabled on both
occasions, because I'm afraid I find that if sites attempt to execute JS
I just get blank pages, whereas if I have it off then at least some of
the time I get a readable alternative.)

If you scroll way to the right of the page you can eventually see
some text appearing about a third of the way across, but almost all the
viewable area before and after that is just a white blank.

(And if you can identify the distorted channel logos at the left-hand
edge, you can click on each one individually to see a complete schedule
for the day on a larger scale then before, e.g.
https://www.tvguide.co.uk/channel/fd66055a-5bc7-51e8-8421-df88e60c98b3/channel-4/1
)


--
Harriet Bazley == Loyaulte me lie ==

But what we need to know is, do people want nasally-insertable computers?
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org