Re: Atari build

V V ned., 31. dec. 2023 ob 00:40 je oseba John-Mark Bell <jmb@netsurf-browser.org> napisala:

> However, the last few versions I had tried would timeout before
> rendering anything.
>
> That was why I was still using build 5366 from 2022.
>
> Yesterday I installed 6637 and it still gives Timeouts. The only page
> that would work was http.  I increased the curl timeout to 300 with no
> change.

All of the support libraries have been upgraded in the last year,
including migrating to OpenSSL 3. These are significant changes so may
have introduced some brokenness at some point.

Sadly, the Atari frontend has no maintainer (any changes are mostly to
make it build after changes to other parts of the code) so, although CI
continues to spit out binary builds, these are never tested (and none of
the core developers has any specific Atari knowledge or any appropriate
hardware/emulator so cannot test them, either).

As ever, if someone is able to work out a fix, we'll happily take a
patch containing it!

 

About Atari release.

Latest nightly build works normally on the FireBee browsing https pages included. It takes some time but it renders them nicely!

So I guess the problem with Atari 68060@60MHz is that it timeouts as it is too slow. @Peter, maybe you can try it in Aranym how NetSurf is working?

As the GUI for Atari builds is not updated can someone point me to the description of the options in choices fill so we can edit it with a text editor?

I would like to know mostly how to enable/disable javascript and CSS rendering? I believe those two options would make page rendering faster.

Vido

Brez virusov.www.avast.com

Re: Atari build

On 29/12/2023 12:02, pslegg@scubadivers.co.uk wrote:
> Hi all,
>
> I hadn't updated Netsurf on my Atari 68060@60MHz) since before January.
>
> I have always found the Atari build to be extremely slow, 5-10 minutes
> or more to render a page being normal and I think it's the ssl that
> hurts it most. So it's not greatly usable but I do use it download
> FreeMint OS updates.

60MHz is not very much to work with, tbh, so I am not entirely surprised
that things are slow, particularly given the ever-increasing complexity
of the modern web.

> However, the last few versions I had tried would timeout before
> rendering anything.
>
> That was why I was still using build 5366 from 2022.
>
> Yesterday I installed 6637 and it still gives Timeouts. The only page
> that would work was http.  I increased the curl timeout to 300 with no
> change.

All of the support libraries have been upgraded in the last year,
including migrating to OpenSSL 3. These are significant changes so may
have introduced some brokenness at some point.

Sadly, the Atari frontend has no maintainer (any changes are mostly to
make it build after changes to other parts of the code) so, although CI
continues to spit out binary builds, these are never tested (and none of
the core developers has any specific Atari knowledge or any appropriate
hardware/emulator so cannot test them, either).

As ever, if someone is able to work out a fix, we'll happily take a
patch containing it!


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

Re: NetSurf 3.11 Released

In article
<CAEEy9dZqxm9OK5GEy75=uxu5f5a=7UHmW10jOb6q+tf1VoSrEA@mail.gmail.com>,
Michael Drake <tlsa@netsurf-browser.org> wrote:
> NetSurf 3.11 is now available to download from

> https://www.netsurf-browser.org/

> The biggest change to the core is improved CSS support, including
> support for the "display: flex" property value, which improves the
> layout of some web pages. There is also a new option in the Choices
> to disable CSS.

> A huge number of other changes have also been made including
> new features, significant performance optimisations, stability
> improvements, and other fixes.

[Snip details]

Many thanks, much appreciated.
B

--
_____________________________________________________________________

Brian Jordan
brian.jordan9@btinternet.com
RISC OS 5.28 (16-Dec-20) on Raspberry Pi
_____________________________________________________________________
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Atari build

Hi all,

I hadn't updated Netsurf on my Atari 68060@60MHz) since before January.

I have always found the Atari build to be extremely slow, 5-10 minutes or more to render a page being normal and I think it's the ssl that hurts it most. So it's not greatly usable but I do use it download FreeMint OS updates.

However, the last few versions I had tried would timeout before rendering anything.

That was why I was still using build 5366 from 2022.

Yesterday I installed 6637 and it still gives Timeouts. The only page that would work was http.  I increased the curl timeout to 300 with no change.

Peter

NetSurf 3.11 Released

NetSurf 3.11 is now available to download from

https://www.netsurf-browser.org/

The biggest change to the core is improved CSS support, including
support for the "display: flex" property value, which improves the
layout of some web pages. There is also a new option in the Choices
to disable CSS.

A huge number of other changes have also been made including
new features, significant performance optimisations, stability
improvements, and other fixes.

Change Log
==========

NetSurf 3.11
------------

### Core / All platforms

* HTML: Fixed failure to reflow SVGs if fetched and ready before layout.
* HTML: Support for `display: flex` layout.
* HTML: Improved minimum/maximum sizes in box layout.
* HTML: Improved handling of percentages.
* HTML: Minor cleaning up of layout code.
* HTML: Use new LibCSS API for unit conversion.
* HTML: Improved ordered list handling.
* CSS: Updated selection callbacks to latest LibDOM API.
* Options: Added core option to disable CSS.
* Options: Added core option to prefer dark mode.
* Options: Improved user choices file processing.
* Bitmap: Opaque testing now implemented in core.
* Bitmap: Added core support for premultiplied-alpha.
* Bitmap: Format logged on startup.
* Bitmap: Added support for pixel colour component order configuration.
* Bitmap: Added colour component order conversion functions.
* Bitmap: Generally more optimal on all platforms for all image formats.
* Image: JPEGXL image handler.
* Image: Compatibility with latest rSVG version.
* Image: Improved handling for broken GIF images.
* Image: Updated to new LibNSGIF API.
* Image: Updated all image format handlers to use new core bitmap capabilities.
* Fetch: Updated to new libcurl API.
* Fetch: Disabled TLS1.0 and TLS1.1.
* Fetch: Improved handling of bad SSL connections.
* Fetch: Change to libcurl to optimise HTTPS connections (upstreamed).
* Local history: More robust rendering.
* Resources: Updated certificate bundle.
* JavaScript: Minor updates to DOM bindings.
* JavaScript: Updated to Duktape 2.7.0 release.
* JavaScript: Console: Don't log through closed window.
* Utility: Cleaned up UTF8 handling.
* Utility: Improved recursive directory removal.
* Utility: Add support for xx_YY format language codes.
* CI: Various improvements to build automation and testing.
* General: Various warning fixes.
* General: Aligned UserAgent with compatibility spec.
* Documentation: Updated URLs to https.
* Documentation: Added front-end development guide.
* Text areas: Clear selection on word left/right.
* Buildsystem: Fixed handling of removed header files.
* Disc cache: Minor fixes.
* Debug: Added generated charts to image cache stats page.
* Debug: Added descendant bounding boxes to HTML box tree dumps.
* Built in: Cleaned up generated `about:` pages.

* LibParserUtils library 0.2.5 (parser building utility functions):
- Optimised consuming from buffer.
- Optimised endian detection.
- Added new API to append vector to buffer.

* Hubbub library 0.3.8 (HTML parser):
- Massively optimised element type detection using perfect hash.
- Optimised and updated performance tester.
- Fixed bitrot in tests.
- Improved example client code.
- Buildsystem improvements.

* LibCSS library 0.9.2 (CSS parser and selection engine):
- Added support for SVG `fill-opacity` property.
- Added support for SVG `stroke-opacity` property.
- Added support for CSS property wide `revert` value.
- Added support for CSS property wide `unset` value.
- Added support for CSS property wide `initial` value.
- Added support for CSS `position` property `sticky` value.
- Added support for CSS `display` property "grid" values.
- Added support for `prefers-color-scheme` media query.
- Added new public API for CSS unit conversion.
- Added support for predefined counter styles.
- Optimised media query handling.
- Made selection code generator deterministic.
- Various selection code generator improvements.
- Squashed leak of system font names.
- Improved internal handling of property units.
- Improved internal string map.
- Minor buildsystem improvements.
- Improved example code.
- Added new tests.

* LibDOM library 0.4.2 (Document Object Model):
- Fixed XML parser error handling.
- Fixed XML parser empty document handling.
- Added DOMTokenList implementation.
- Added DOM tree walking function.
- Improved example code.
- Fixed HTML Element int32 attribute getter to handle signed values.
- Various stability improvements.
- Buildsystem improvements.

* LibNSGIF library 1.0.0 (GIF support):
- Complete rewrite.
- New API that doesn't expose internal state.
- Much better handling of bad or broken GIFs.
- Support for decoding to client's choice of pixel colour component order.
- Many fixes.
- Faster decoding.
- Updated documentation.

* LibSVGTiny library 0.1.8 (SVG support):
- Fixed X11 example utility build.
- Implemented path arc correctly.
- Updated documentation.

### RISC OS-Specific

* Removed last vestiges of plugin support.
* Added Choices option to disable CSS.
* Updated licence information.
* Updated links to use https in documentation.
* Fixed broken links in documentation.
* Support for building with `arm-riscos-gnueabi` toolchain.
* Updated bundled resources.
* Improved bitmap rendering.
* Fixed EX0 EY0 "high DPI" rendering.
* Text selection support in URL bar (RO5.28 onwards).
* Dragging favicon saves whole URL.
* Updated to new RUfl API.
* Fixed font scanning on startup behaviour.
* Unified redraw code for browser windows and other core-rendered windows.
* Fixed auto-scroll crash when pointer leaves core window.
* Allow drag and drop loading of WEBP image format.

* RUfl library 0.1.0 (RISC OS Unicode support):
- Added astral character support.
- RUfl_cache version now in filename.
- Support for multiple versions of RUfl_cache coexisting.
- Substitution table reworked for astral characters and heavily optimised.
- Render 6-digit replacements for codepoints outside Basic Multilingual Plane.
- Refactoring and many code improvements.
- Support for UCS-aware Encoding files.
- Various API changes.
- Detect overlong and invalid UTF-8 sequences.
- Improved compatibility with different Font Manager versions.
- Fixed menu building to cope with system with no fonts.
- Ignore UCS fonts if using a non-UCS Font Manager.
- Remove assumption that pointers are 32-bit.
- Added test infrastructure and many tests.
- Buildsystem improvements.

### GTK-Specific

* Cleaned up initialisation.
* Various build warning fixes.
* Fixed crash when destroying scaffolding.
* Don't create zero-sized bitmaps.
* Configure core to use Cairo's bitmap format.
* Added support for cursor word left/right key bindings.
* Added support for delete word left/right key bindings.
* Added back/forward mouse button processing.
* Fixed path plotter.
* Made UI resources more consistent.

### Amiga-Specific

* Added page theme option.
* Improved bitmap handling.
* Improved and optimised Unicode handling.
* Stability improvements.

### Windows-Specific

* Buildsystem: Use pkg-config.
* Support Ctrl+A in address bar.

### Framebuffer-Specific

* Minor internal font fixes.
* Improved documentation.

Also included are many smaller bug fixes, improvements and
documentation enhancements.


Best regards,
The NetSurf Team
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

[Rpcemu] Real floppy support

RPCEmu is a very good program but I miss real floppy support.


Micky

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] GCCSDK 10 for older cores

On 22/04/2022 17:29, Steffen Huber wrote:
> Hi,
>
>> Rob Kendrick <rjek@rjek.com> wrote:
> [snip]
>> Is building code for ARMv3 (or v4?) supported and I'm being an idiot, or
>> is this totally out of scope of the endeavour?
>
> No idea about the GCCSDK details, but from a GCC-ARM-backend perspective,
> ARMv4 and everything-non-Thumb-before-ARMv6 was deprecated I think in
> GCC 6, so I guess it was removed from the ARM backend in one of the
> later versions.

Certainly, ARMv4 (no T) is still deprecated in GCC 13. Support remains,
however (my understanding is that removing it will necessitate removing
support for various StrongARM variants and there was push-back against
that when all the other non-Thumb architecture variants were removed in
2018). So, in practice, it's still there, is understood, and produces
the code you would expect.

[Aside: you could still probably get away with using ARMv4T here anyway
and building all the compilation units in ARM mode as no interworking is
actually necessary].

[...]

> So unless you re-add the support to the ARM backend, I guess you
> are out of luck and need to go back to GCC 4.7.x for old ARM
> architecture compatibility.

There is still one gotcha if you want to support Acorn hardware: the
RiscPC bus doesn't support halfword (16bit) accesses, so LDRH/STRH do
not work. Teaching the compiler not to emit these instructions turns out
to be fairly trivial, however.

Some time ago, we put all of this together to produce a GCC10-based
toolchain that will build for ARMv4 (using softfloat) and using EABI
calling conventions. The resulting binaries (whether statically or
dynamically linked) require ARMEABISupport and so require RISC OS 5
(unless I've misinterpreted ARMEABISupport's use of the PMP dynamic area
APIs). In terms of hardware compatibility, StrongARM RiscPCs are the
minimum thing supported (as ARMv4 is the minimum supported architecture,
all ARM610/710/7500(FE)-based systems are ruled out but all other
post-Acorn systems should be fine).

The full set of changes can be found at:

https://git.netsurf-browser.org/toolchains.git/tree/arm-riscos-gnueabi/

and the commit messages are probably reasonably instructive as to what
is changing and why:

https://git.netsurf-browser.org/toolchains.git/log/arm-riscos-gnueabi

(The squash-merge introducing the toolchain is disaggregated here:
https://git.netsurf-browser.org/toolchains.git/log/?h=jmb/arm-riscos-gnueabihf
in case that's of use to anyone)

As implied by the directory name, the system triplet
(arm-riscos-gnueabi) differs from the arm-riscos-gnueabihf used by the
GCC10 in the autobuilder (as the ABIs are *not* compatible -- the "hf"
one requires ARMv7 and VFP hard float). This is reasonably analogous to
the Debian armel/armhf architecture split, so should not be unreasonably
confusing.

John Tytgat's original GCCSDK makefile was resurrected as part of this
work, so it builds in pretty much the same way as the GCC 4-based GCCSDK
does (which much better fits the NetSurf toolchain requirements than the
rules in the autobuilder).

Most of the other patches should be fairly obvious (the POSIX locales
one was upstreamed aeons ago, so is already in UnixLib proper). There
are probably two items that deserve special mention:

1. elf2eif has had some significant surgery to ensure that static
binaries using EABI work properly:
a: enabling ARMEABISupport's abort handling at process start
b: ensuring that the GOTT_BASE pointer at &8038 is filled in

2. UnixLib's stack unwinding has been reworked significantly for the
EABI case (and refactored in the APCS case). Successful EABI unwinding
requires the presence of unwind tables (i.e. building with
-funwind-tables), however.

Hopefully this is of use to somebody!


John-Mark.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [Rpcemu] Linux Home driretory next to my HostFS drive

On 18/11/2023 12:55, riscos@markerdesign.be wrote:
> Hello,
>
> I have two versions of RPCEmu running on my Linux laptop and have
> created Symlinks to access my USB drives. So far, so good, so happy.
>
> Now I would like the Linux Home directory to appear next to my HostFS
> drive on the taskbar, and or is there a way to make symlinks appear on
> the taskbar (either as a folder or as a drive).
>
> Does anyone have any experience with this?
>
Just noticed this, dunno if you worked it out yet? You don'd say what
RISC OS you are running or indeed which RPCEmu .

Using RISCOS 3.7 here and 0.9.4.  To achieve what it sounds like you are
after, you could create a symbolic link inside your HostFS directory,
pointing to your home directory. Then use 'AddTinyDir'.

From the command line, something like;

AddTinyDir HostFS::HostFS.$.Home

where home is the symbolic link you created. Create an obey file and
have it run on each boot to make it persistant.

I think pinboard in RISC OS 5 can do that.

--
Michael Howard.

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: allocator_claim_pages:449

On 1 Dec 2023 as I do recall,
John-Mark Bell wrote:

> On 01/12/2023 09:57, Martin Avison wrote:
> > In article <8e67b10b5b.harriet@bazleyfamily.co.uk>,
> > Harriet Bazley <lists@bazleyfamily.co.uk> wrote:

[snip]


> >> allocator_claim_pages:449 - Unknown dynamic area
> >
> >> Reporter 2.72 (15 Aug 2020) Listed 10 lines
> >
> > They do not look like messages caused by a RISC OS error being raised,
> > but more like messages produced by a specific Reporter call within
> > the program.
>
> These appear to emitted by the ARMEABISupport module. There is, to my
> knowledge, no "official" release build of this, so we made sure to
> provide the same binary as was being shipped by other applications to
> ensure that everything was consistent. That may well mean that it's
> actually a debug build of the module, hence the logging.

Yes, I got 'unknown dynamic area release'-type messages later, when I
had to Alt-Break Netsurf. (Doesn't seem to happen on a normal quit.)

--
Harriet Bazley == Loyaulte me lie ==

The saddest words in the English language are 'Too' and 'late'
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Re: allocator_claim_pages:449

On 01/12/2023 09:57, Martin Avison wrote:
> In article <8e67b10b5b.harriet@bazleyfamily.co.uk>,
> Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
>> Since downloading v6511 of Netsurf I keep seeing "Unknown dynamic
>> area" errors pop up in my Reporter window. These are 'silent'
>> errors that don't generate a WIMP error box, so presumably the user
>> is not supposed to be aware of them, but it gives the impression
>> that the app is running out of memory....
>
>> Reporter 2.72 (15 Aug 2020) List Fri 1st Dec 2023 01:11
>
>> 01:06:46.54 ** Clear ** from Menu
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>> allocator_claim_pages:449 - Unknown dynamic area
>
>> Reporter 2.72 (15 Aug 2020) Listed 10 lines
>
> They do not look like messages caused by a RISC OS error being raised,
> but more like messages produced by a specific Reporter call within
> the program.

These appear to emitted by the ARMEABISupport module. There is, to my
knowledge, no "official" release build of this, so we made sure to
provide the same binary as was being shipped by other applications to
ensure that everything was consistent. That may well mean that it's
actually a debug build of the module, hence the logging.


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

Re: allocator_claim_pages:449

In article <8e67b10b5b.harriet@bazleyfamily.co.uk>,
Harriet Bazley <lists@bazleyfamily.co.uk> wrote:
> Since downloading v6511 of Netsurf I keep seeing "Unknown dynamic
> area" errors pop up in my Reporter window. These are 'silent'
> errors that don't generate a WIMP error box, so presumably the user
> is not supposed to be aware of them, but it gives the impression
> that the app is running out of memory....

> Reporter 2.72 (15 Aug 2020) List Fri 1st Dec 2023 01:11

> 01:06:46.54 ** Clear ** from Menu
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area
> allocator_claim_pages:449 - Unknown dynamic area

> Reporter 2.72 (15 Aug 2020) Listed 10 lines

They do not look like messages caused by a RISC OS error being raised,
but more like messages produced by a specific Reporter call within
the program.

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

allocator_claim_pages:449

Since downloading v6511 of Netsurf I keep seeing "Unknown dynamic area"
errors pop up in my Reporter window. These are 'silent' errors that
don't generate a WIMP error box, so presumably the user is not supposed
to be aware of them, but it gives the impression that the app is running
out of memory....

Reporter 2.72 (15 Aug 2020) List Fri 1st Dec 2023 01:11

01:06:46.54 ** Clear ** from Menu
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area
allocator_claim_pages:449 - Unknown dynamic area

Reporter 2.72 (15 Aug 2020) Listed 10 lines


--
Harriet Bazley == Loyaulte me lie ==

You cannot propel yourself forward by patting yourself on the back.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org

Pull request: CSS support for libsvgtiny

As promised, and only a month late. My branch is available at,

https://gitweb.michael.orlitzky.com/libsvgtiny.git libcss

For best results, you should also apply the libcss patch I recently
posted that makes fill- and stroke-opacity inherited properties.

No major issues remain. There's a test suite in test/css consisting
of a bunch of SVG files that you can open side-by-side in the
libsvgtiny example program and your favorite image viewer. With the
libcss patch, they all pass (compared to firefox). Without it, two
fail.

If you recall, there was some concern about the licensing of the
select handlers. I think I spent enough time learning and rewriting
the handlers to alleviate those concerns; I ultimately did not copy
anything from NetSurf, although naturally many of the handlers look
similar (and of course I reimplemented them *after* looking at the
NetSurf handlers, so you be the judge).

A summary of the changes follows.

----------------------------------------------------------------
Michael Orlitzky (88):
src/svgtiny_internal.h: removed commented libcss stub
src/svgtiny.c: remove old misleading libcss comments
Makefile: build against libcss
README: mention that libcss is required
src/svgtiny_internal.h: add CSS context to parser state
src/svgtiny_strings.h: add "media" to the list of strings
include/svgtiny.h: add new error constant svgtiny_LIBCSS_ERROR
README: document the new svgtiny_LIBCSS_ERROR code
src/svgtiny.c: initialize the libcss context in svgtiny_parse()
src/svgtiny.c: add impotent svgtiny_preparse_styles() function
src/svgtiny_css.c: new file with new svgtiny_resolve_url() function
src/svgtiny_internal.h: add svgtiny_resolve_url() prototype
src/Makefile: add the new svgtiny_css.c to the list of sources
src/svgtiny.c: add svgtiny_parse_style_element() function and use it
src/svgtiny_css.c: new function svgtiny_create_stylesheet()
src/svgtiny_internal.h: add svgtiny_create_stylesheet() prototype
src/svgtiny.c: use svgtiny_create_stylesheet() to parse <style>
src/svgtiny_internal.h: drop svgtiny_resolve_url() prototype
src/svgtiny.c: add svgtiny_parse_style_inline() function
src/svgtiny.c: parse inline stylesheet in svgtiny_parse_paint_attributes()
src/svgtiny{.c,_internal.h}: intern SVG's XML namespace URI
src/svgtiny_css.c: implement node_name() select handler
src/svgtiny_css.c: implement node_classes() select handler
src/svgtiny_strings.h: intern "id" for libcss
src/svgtiny_css.c: implement node_id() select handler
src/svgtiny_css.c: implement named_parent_node() select handler
src/svgtiny_css.c: implement named_sibling_node() select handler
src/svgtiny_css.c: implement named_generic_sibling_node() select handler
src/svgtiny_css.c: implement parent_node() select handler
src/svgtiny_css.c: implement sibling_node() select handler
src/svgtiny_strings.h: intern the universal selector string "*"
src/svgtiny_css.c: implement node_has_name() select handler
src/svgtiny_css.c: implement node_has_class() select handler
src/svgtiny_css.c: implement node_has_id() select handler
src/svgtiny_css.c: implement node_has_attribute() select handler
src/svgtiny_css.c: implement node_has_attribute_equal() select handler
src/svgtiny_css.c: implement node_has_attribute_dashmatch() select handler
src/svgtiny_css.c: implement node_has_attribute_includes() select handler
src/svgtiny_css.c: implement node_has_attribute_prefix() select handler
src/svgtiny_css.c: implement node_has_attribute_suffix() select handler
src/svgtiny_css.c: implement node_has_attribute_substring() select handler
src/svgtiny_css.c: implement node_is_root() select handler
src/svgtiny_css.c: implement node_count_siblings() select handler
src/svgtiny_css.c: implement node_is_empty() select handler
src/svgtiny_css.c: implement node_is_link() select handler
src/svgtiny_css.c: implement node_is_hover() select handler
src/svgtiny_css.c: implement node_is_active() select handler
src/svgtiny_css.c: implement node_is_focus() select handler
src/svgtiny_css.c: implement node_is_enabled() select handler
src/svgtiny_css.c: implement node_is_disabled() select handler
src/svgtiny_css.c: implement node_is_checked() select handler
src/svgtiny_css.c: implement node_is_target() select handler
src/svgtiny_css.c: case-insensitivity for node_has_attribute_substring()
src/svgtiny_css.c: implement node_is_lang() select handler
src/svgtiny_css.c: implement ua_default_for_property() select handler
src/svgtiny_css.c: implement node_is_visited() select handler
src/svgtiny_strings.h: intern a "userdata" key string
src/svgtiny_css.c: implement set_libcss_node_data() select handler
src/svgtiny_css.c: implement get_libcss_node_data() select handler
src/svgtiny_css.c: implement node_presentational_hint() select handler
src/svgtiny_css.c: implement named_ancestor_node() select handler
src/svgtiny_css.c: define a css_select_handler
src/svgtiny_css.c: add user handler function
src/svgtiny_css.c: use our userdata handler in set_libcss_node_data()
src/svgtiny_css.c: add svgtiny_select_style() wrapper
src/svgtiny_internal.h: add svgtiny_select_style() to the header
src/svgtiny_internal.h: add fill/stroke_opacity to the parse state struct
src/svgtiny.c: eliminate pointless NULL check
examples/svgtiny_display_x11.c: handle svgtiny_LIBCSS_ERROR
test/decode_svg.c: handle svgtiny_LIBCSS_ERROR
src/svgtiny.c: parse styles in svgtiny_parse_paint_attributes()
include/svgtiny.h: add fill_opacity and stroke_opacity to svgtiny_shape
src/svgtiny.c: set shape opacities from the parser state
examples/svgtiny_display_x11.c: use opacity information
src/svgtiny.c: update the docstring for svgtiny_parse_svg()
src/svgtiny.c: use separate function for style application
src/svgtiny_internal.h: add parent style to the parser state
src/svgtiny*.{c,h}: move the libcss unit context into the parser state
src/svgtiny.c: implement composition of parent styles
src/svgtiny_css.c: add some default user-agent properties after all
src/svgtiny.c: remove parent == NULL hack
examples/GNUmakefile: add a GNUmakefile for the example program
examples/svgtiny_display_x11.c: update build instructions
examples/.gitignore: ignore the compiled example program
src/svgtiny.c: use case-sensitive comparisons for SVG element names
test/css: add some visually-verified test cases for our new features
src/svgtiny_css.c: clean trailing newlines
src/svgtiny.c: whitespace cleanup (spaces to tabs)

Makefile | 8 +-
README | 13 +-
examples/.gitignore | 2 +
examples/GNUmakefile | 20 +
examples/svgtiny_display_x11.c | 55 +-
include/svgtiny.h | 5 +-
src/Makefile | 2 +-
src/svgtiny.c | 494 ++++++++++--
src/svgtiny_css.c | 2069 ++++++++++++++++++++++++++++++++++++++++++++++++++
src/svgtiny_internal.h | 37 +-
src/svgtiny_strings.h | 4 +
test/css/README | 11 +
test/css/attributes.svg | 94 +++
test/css/case-sensitive-elements.svg | 19 +
test/css/empty-pseudo-class.svg | 33 +
test/css/id-and-class.svg | 49 ++
test/css/inherit.svg | 43 ++
test/css/inline.svg | 31 +
test/css/lang.svg | 32 +
test/css/link-pseudo-class.svg | 36 +
test/css/node-name.svg | 40 +
test/css/nth-child.svg | 52 ++
test/css/root.svg | 25 +
test/css/siblings-and-descendants.svg | 64 ++
test/css/styles-at-end.svg | 29 +
test/decode_svg.c | 3 +
26 files changed, 3169 insertions(+), 101 deletions(-)
create mode 100644 examples/.gitignore
create mode 100644 examples/GNUmakefile
create mode 100644 src/svgtiny_css.c
create mode 100644 test/css/README
create mode 100644 test/css/attributes.svg
create mode 100644 test/css/case-sensitive-elements.svg
create mode 100644 test/css/empty-pseudo-class.svg
create mode 100644 test/css/id-and-class.svg
create mode 100644 test/css/inherit.svg
create mode 100644 test/css/inline.svg
create mode 100644 test/css/lang.svg
create mode 100644 test/css/link-pseudo-class.svg
create mode 100644 test/css/node-name.svg
create mode 100644 test/css/nth-child.svg
create mode 100644 test/css/root.svg
create mode 100644 test/css/siblings-and-descendants.svg
create mode 100644 test/css/styles-at-end.svg
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

[PATCH 1/1] src/select/dispatch.c: fill-opacity and stroke-opacity are inherited

These two SVG properties were copied from the CSS4 "opacity" property
that is not inherited:

https://www.w3.org/TR/css-color-4/#transparency

However, both fill-opacity and stroke-opacity _are_ inherited:

https://www.w3.org/TR/SVG2/painting.html#FillOpacity
https://www.w3.org/TR/SVG2/painting.html#StrokeOpacity

To fix the copy-paste error, this commit toggles the "inherited" bit
in the dispatch table for those two properties.
---
src/select/dispatch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/select/dispatch.c b/src/select/dispatch.c
index 74bc6ed..cee9335 100644
--- a/src/select/dispatch.c
+++ b/src/select/dispatch.c
@@ -517,10 +517,10 @@ struct prop_table prop_dispatch[CSS_N_PROPERTIES] = {
},
{
PROPERTY_FUNCS(fill_opacity),
- 0,
+ 1,
},
{
PROPERTY_FUNCS(stroke_opacity),
- 0,
+ 1,
}
};
--
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: libcss node_data cleanup issue

On Wed, 2023-11-15 at 19:07 -0500, Michael Orlitzky wrote:
>
> if (node_data->bloom != NULL) {
> free(node_data->bloom);
> }
>
> So, ultimately, we try to free the static empty_bloom. This does not
> work.
>

It turns out that providing user-agent defaults for a few properties
avoids this code path. How? I don't know. But those same defaults also
appear necessary for parent/child style composition to work, making the
issue above somewhat less pressing.

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

[Rpcemu] Linux Home driretory next to my HostFS drive

Hello,

I have two versions of RPCEmu running on my Linux laptop and have
created Symlinks to access my USB drives. So far, so good, so happy.

Now I would like the Linux Home directory to appear next to my HostFS
drive on the taskbar, and or is there a way to make symlinks appear on
the taskbar (either as a folder or as a drive).

Does anyone have any experience with this?

--
Kind regards, Steve


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] sizeof structs

 

typedef union {

uint16_t cache;

struct {

uint8_t code;

uint8_t arg;

} __attribute__((__packed__)) op;

} __attribute__((__packed__)) _Py_CODEUNIT;

 

typedef struct { } __attribute__((__packed__)) _PyAttrCache;

 

Aha. Thanks. That's got it past that static assert at least :)

You have to pack the nested structs as well. That's what I had to do

with harfbuzz for GCC 4.

I think that's the bit I missed.

Are you dynamic linking? The only issue with GCC 10 is we don't have a

point of distribution for the shared libraries. If you're static

linking then you don't have to worry about that.

 

Ah. yeah I am. I guess this is why Iris needs to come with it's own set of shared libs?

 

Cheers

 

Chris

 

Re: [gccsdk] sizeof structs

On 16/11/2023 09:46, Chris Johns wrote:
> Hello
> I thought I'd have a go at building Python 3.12. While ro-config step
> works (with the patch from 3.11), trying the build fails with a static
> assertion "incorrect cache size".
I remember quite some time ago (wow, nearly 10 years according to the
autobuilder log) having similar problems with harfbuzz and GCC 4. If you
look at the recipe in the autobuilder, you'll see a lot of the patches
are to add packing to structs. I remember it was quite tedious because
the structs tended to be nested so packing one affected another, but
eventually I got it working.

Looking at my local version that I'm using with GCC 10, I see that I am
not applying these patches, and IIRC, came to the conclusion that GCC
10 packed structs by default whereas GCC 4 didn't.

> From a look at the code, it seems to be related to the size of some
> structs .. for example
>
> typedef union {
> uint16_t cache;
> struct {
> uint8_t code;
> uint8_t arg;
> } op;
> } _Py_CODEUNIT;
> and
> typedef struct {
> uint16_t counter;
> uint16_t version[2];
> uint16_t index;
> } _PyAttrCache;
> The assert that INLINE_CACHE_ENTRIES_STORE_ATTR == 4
> So what is that doing?
> #define CACHE_ENTRIES(cache) (sizeof(cache)/sizeof(_Py_CODEUNIT))
> #define INLINE_CACHE_ENTRIES_STORE_ATTR CACHE_ENTRIES(_PyAttrCache)
> So from a naive point of view, it should be fine .. sizeof(_Py_CODEUNIT)
> is 2 bytes (a uniion of a 16 bit int or 2 8-bit ones),
> sizeof(_PyAttrCache) is 8 bytes (4 16-bit int (two plus two in the array).
> However, while sizeof(_PyAttrCache) is indeed 8, sizeof(_PyCODEUNIT) is
> 4 (I am guessing it's being rounded up to a word).
> I'm using gcc 4.7.4 (cross compiler). I have tried targetting a later
> CPU, and I did try setting the packed, aligned=2 on the _Py_CODEUNIT
> struct but that didn't seem to make any difference.

When you say you tried setting the packed, aligned=2, did you try:

typedef union {
uint16_t cache;
struct {
uint8_t code;
uint8_t arg;
} __attribute__((__packed__)) op;
} __attribute__((__packed__)) _Py_CODEUNIT;

typedef struct { } __attribute__((__packed__)) _PyAttrCache;

You have to pack the nested structs as well. That's what I had to do
with harfbuzz for GCC 4.

> Any other suggestions? Later gcc? Some other options? I guess python
> probably shouldn't be assuming the sizes, but I'm not sure about getting
> that changed :)

I suspect GCC 10 may do a better job as, like I say, harfbuzz seems to
work without patches to pack the structs. Admittedly, I didn't do any
actually testing, I just went off the fact that it built without the
static assertions failing and Webkit produced readable text!

> I'm not too worried if it means python 3.12 is limited to more modern
> mechines. 3.8 works on everything else.

Are you dynamic linking? The only issue with GCC 10 is we don't have a
point of distribution for the shared libraries. If you're static
linking then you don't have to worry about that.

Lee.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] sizeof structs

Hello

 

I thought I'd have a go at building Python 3.12. While ro-config step works (with the patch from 3.11), trying the build fails with a static assertion "incorrect cache size".

 

From a look at the code, it seems to be related to the size of some structs .. for example

 

typedef union {
uint16_t cache;
struct {
uint8_t code;
uint8_t arg;
} op;
} _Py_CODEUNIT;

 

and

 

typedef struct {
uint16_t counter;
uint16_t version[2];
uint16_t index;
} _PyAttrCache;

 

The assert that INLINE_CACHE_ENTRIES_STORE_ATTR == 4

 

So what is that doing?

 

#define CACHE_ENTRIES(cache) (sizeof(cache)/sizeof(_Py_CODEUNIT))

#define INLINE_CACHE_ENTRIES_STORE_ATTR CACHE_ENTRIES(_PyAttrCache)

 

So from a naive point of view, it should be fine .. sizeof(_Py_CODEUNIT) is 2 bytes (a uniion of a 16 bit int or 2 8-bit ones), sizeof(_PyAttrCache) is 8 bytes (4 16-bit int (two plus two in the array).

 

However, while sizeof(_PyAttrCache) is indeed 8, sizeof(_PyCODEUNIT) is 4 (I am guessing it's being rounded up to a word).

 

I'm using gcc 4.7.4 (cross compiler). I have tried targetting a later CPU, and I did try setting the packed, aligned=2 on the _Py_CODEUNIT struct but that didn't seem to make any difference.

 

Any other suggestions? Later gcc? Some other options? I guess python probably shouldn't be assuming the sizes, but I'm not sure about getting that changed :)

 

I'm not too worried if it means python 3.12 is limited to more modern mechines. 3.8 works on everything else.

 

 

Cheers

 

Chris

libcss node_data cleanup issue

I'm still making progress on this, but fixed some crashes today that
may belong to libcss. The css_select__initialise_selection_state()
function initializes node_data->bloom with the parent's bloom filter:

error = css__get_parent_bloom(parent, handler, pw,
&state->node_data->bloom);

But when "parent" is NULL, that function returns

static css_bloom empty_bloom[CSS_BLOOM_SIZE];
bloom = empty_bloom;
*parent_bloom = bloom;
return CSS_OK;

The matching call to css_select__finalise_selection_state() eventually
tries to free that data:

if (state->node_data != NULL) {
css__destroy_node_data(state->node_data);
}

And that involves

if (node_data->bloom != NULL) {
free(node_data->bloom);
}

So, ultimately, we try to free the static empty_bloom. This does not
work.

Since this only happens when "parent" is NULL, I can easily check for
that case and avoid calling css_select_style(). But is that the right
thing to do? Or is this a corner case that css_select_style() should
handle?
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

FOSDEM 2024 (Feb 3&4, Brussels, EU) - Retrocomputing Devroom - Call for papers

The CfP has been published:

https://lists.fosdem.org/pipermail/fosdem/2023q4/003515.html

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

Re: libcss fill- and stroke-opacity

On Sun, 2023-10-01 at 10:54 +0100, John-Mark Bell wrote:
> >
> > Looks good to me, thanks. One minor thing (that you inherited from the
> > existing opacity implementation) is the bogus use of CSS_Z_INDEX_SET in
> > the cascade for these properties. I've fixed that for the opacity property.
> >
> > I'll tidy that while merging -- I'm going to squash your changes down to
> > a pair of commits -- one for each new property (but I very much
> > appreciate the fine granularity of the series -- very easy to review).
>
> Done:
>
> * https://git.netsurf-browser.org/libcss.git/commit/?id=d6e9f636
> * https://git.netsurf-browser.org/libcss.git/commit/?id=76ccb5b6
>

Thank you!

I have some planned downtime in 1.5 weeks that I'll use to work on the
corresponding libsvgtiny changes.
_______________________________________________
netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org
To unsubscribe send an email to netsurf-dev-leave@netsurf-browser.org

Re: libcss fill- and stroke-opacity

On 01/10/2023 10:03, John-Mark Bell wrote:
> On 19/09/2023 23:28, Michael Orlitzky wrote:
>> 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.
>
> [snip]
>
> Looks good to me, thanks. One minor thing (that you inherited from the
> existing opacity implementation) is the bogus use of CSS_Z_INDEX_SET in
> the cascade for these properties. I've fixed that for the opacity property.
>
> I'll tidy that while merging -- I'm going to squash your changes down to
> a pair of commits -- one for each new property (but I very much
> appreciate the fine granularity of the series -- very easy to review).

Done:

* https://git.netsurf-browser.org/libcss.git/commit/?id=d6e9f636
* https://git.netsurf-browser.org/libcss.git/commit/?id=76ccb5b6


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

Re: libcss fill- and stroke-opacity

On 19/09/2023 23:28, Michael Orlitzky wrote:
> 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.

[snip]

Looks good to me, thanks. One minor thing (that you inherited from the
existing opacity implementation) is the bogus use of CSS_Z_INDEX_SET in
the cascade for these properties. I've fixed that for the opacity property.

I'll tidy that while merging -- I'm going to squash your changes down to
a pair of commits -- one for each new property (but I very much
appreciate the fine granularity of the series -- very easy to review).


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

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

Re: Hotlist window issue

On 28 Aug 2023 as I do recall,
Rob Kendrick wrote:

> On Sun, Aug 27, 2023 at 11:37:26PM +0100, Harriet Bazley wrote:
> > I've just noticed that the same thing applies to the global history
> > window - if I check that in WinEd, the history window in the Templates
> > file has *neither* 'Allow off screen' nor 'Keep on screen' flags set.
>
> Both of these use the "tree" template, whose source can be found here:
> http://git.netsurf-browser.org/netsurf.git/tree/frontends/riscos/templates/en#n2605

Thanks for the pointer - I've spent a lot of time fiddling around with
the settings of those two flags in !NetSurf.Resources.en.Templates.tree,
and so far as I can tell the only setting that can prevent the window
from resizing itself off the bottom of the screen is to have 'Keep on
screen' (bit 13) ON and 'Allow off screen' (bit 6) OFF. Which is rather
more stringent than actually desirable, because it then makes it
impossible for any part of that window ever to be outside the screen
ever, which is *not* normal Wimp behaviour, but it's the only
combination of flags that appears to produce the desired result of
jumping up to the top of the screen to use the maximum visible area when
the size is toggled.

I can only assume that the 'standard' RISC OS behaviour (as displayed by
NetSurf's main browser window for instance) of forcing the window
onscreen when the user requests a toggle to maximum size, but permitting
it to be dragged partially offscreen thereafter, requires some kind of
application redraw rather than being handled entirely by the WIMP?

--
Harriet Bazley == Loyaulte me lie ==

A poor workman blames his tools.
_______________________________________________
netsurf-users mailing list -- netsurf-users@netsurf-browser.org
To unsubscribe send an email to netsurf-users-leave@netsurf-browser.org