[Netsurf-develop] Font / Unicode overview
by James Bursa
In an attempt to answer the questions that have appeared recently,
I've written a guide to fonts and Unicode support in NetSurf.
James
______________________________________________________________________
Fonts in NetSurf
NetSurf has support for displaying pages containing Unicode characters
that aren't normally available on RISC OS, for example accented Latin
letters, Greek, Cyrillic, Japanese, and various symbols.
The font choices let you pick a font for each of the five standard
families available to web authors (in CSS). The choices specify the
preferred font to use. If a character is not available in the chosen
font, but it's present in some other font that you have installed,
then NetSurf will automatically use it. There's no need to change the
font choices to view pages with characters that are not available in
the chosen font.
Note that you can only choose a font family. NetSurf will
automatically use weights from the family for bold and slanted text,
if available.
Installing more fonts
The fonts that come with RISC OS cover Latin (Homerton, Trinity,
Corpus), Greek (Sidney), and various symbols (Selwyn, Sidney). (On
RISC OS 3-4, only the "Latin 1" characters from the standard fonts,
which cover Western European languages, can be used by NetSurf).
If you want to display pages with other characters correctly, you'll
need to install fonts containing them. When a character is not present
in any available font, the Unicode character code will be displayed.¹
Any font supplied with a correctly designed "Encoding" file should
work. In practice, native fonts covering anything other than Latin 1
are rare. The solution is to convert TrueType fonts using TTF2f (this
currently produces fonts suitable for RISC OS 5 only).
After installing new fonts, NetSurf will need restarting so that it
detects them.
Problems and unimplemented features
* The default font is always the sans-serif one.
* Printing on RISC OS 5 doesn't work, due to lack of support in the
Font Manager and printer drivers. Printing to Postscript printers on
RISC OS 3-4 is not correctly implemented in NetSurf.
* Substituted characters are taken from the first font that contains
them, even if a character which matches the weight or slant better
is available.
* Only two weights (regular and bold) are supported, even if a family
contains other weights. The algorithm that finds weights needs
improving, for example using the heuristics given in CSS 2.1 15.6.
* Drawfile export is broken.
* Right-to-left text (Hebrew, Arabic) is not implemented.
____________________
¹ If you see the codes 0091, 0092, 0096, or others starting 009, that
indicates that the page is not specifying the character set that it
is using correctly. Installing fonts won't help. We haven't yet
decided what the best way to work around this problem is.
16 years, 5 months
[Netsurf-develop] Accented chars lost
by Jerome Mathevet
With Test Build (27 Jun 2005 02:00), I notice that accented characters
have disappeared in the status window (shows up with fr ressources).
They display OK in the main page (HTML). It might be something to do
with the recent UnixLib because now a comma is used instead of the
decimal dot.
--
Jérôme Mathevet
17 years, 10 months
[Netsurf-develop] Netsurf crash on 150%
by Jan-Jaap van der Geer
I found a repeatable crash.
Open a NetSurf window.
Set it to zoom 150%
Open this page: http://www.drobe.co.uk/riscos/artifact1385.html
After the last object is loaded (or just before) it blanks the
screen and crashes, leaving a big (3450K but I think it varies)
stderr behind. This is maybe the important bit in that file:...
Error 0x80000200: Floating point exception: invalid operation
pc: 00171f9c
f0: -3221225472.000000 f1: 619.000000 f2: 160.000000 f3: 0.000000
f4: 1.000000 f5: 1.500000 f6: 1.500000 f7: 0.000000
fpsr: 1070010
Fatal signal received: Floating point exception
Stack backtrace:
( 284f40) pc: 9d71c lr: 13429c sp: 284f44 __write_backtrace()
( 284fe4) pc: 133df8 lr: 24e8fc sp: 284fe8 __unixlib_raise_signal()
( 284ff4) pc: 24e7fc lr: 11a9cc sp: 28369c UnixLibErrorHandler()
( 283730) pc: 171ec0 lr: 11a9cc sp: 283734 ^html_redraw_box()
( 283764) pc: 11a940 lr: 6999c sp: 283768 html_redraw()
( 283798) pc: 698f8 lr: 1c88a4 sp: 28379c content_redraw()
( 283808) pc: 1c84f0 lr: 66950 sp: 28380c ro_gui_window_redraw()
( 28381c) pc: 66788 lr: 1e1cd8 sp: 283820 ^ro_gui_redraw_window_request()
( 28382c) pc: 1e1c64 lr: 1e1de4 sp: 283830 ^ro_gui_handle_event()
( 283944) pc: 1e1d70 lr: 1710a4 sp: 283948 gui_multitask()
( 283994) pc: 171054 lr: 1cd340 sp: 283998 layout_block_context()
( 283a08) pc: 1cc904 lr: 171148 sp: 283a0c ^layout_table()
( 283a58) pc: 171054 lr: 1cd340 sp: 283a5c layout_block_context()
( 283acc) pc: 1cc904 lr: 171148 sp: 283ad0 ^layout_table()
( 283b1c) pc: 171054 lr: 1cd340 sp: 283b20 layout_block_context()
( 283b90) pc: 1cc904 lr: 171148 sp: 283b94 ^layout_table()
( 283be0) pc: 171054 lr: 1cd340 sp: 283be4 layout_block_context()
( 283c54) pc: 1cc904 lr: 171148 sp: 283c58 ^layout_table()
( 283ca4) pc: 171054 lr: 1cd340 sp: 283ca8 layout_block_context()
( 283d18) pc: 1cc904 lr: 171148 sp: 283d1c ^layout_table()
( 283d68) pc: 171054 lr: 11a900 sp: 283d6c layout_block_context()
( 283d84) pc: 11a864 lr: 6dafc sp: 283d88 layout_document()
( 283d98) pc: 6daec lr: 1d012c sp: 283d9c html_reformat()
( 283df4) pc: 1d009c lr: 610e8 sp: 283df8 content_reformat()
( 283e44) pc: 60bd8 lr: 7e36c sp: 283e48 ^html_object_callback()
( 283e94) pc: 7e2e0 lr: 1c30b0 sp: 283ea0 content_broadcast()
( 283f00) pc: 1c2ef4 lr: 196890 sp: 283f04 content_convert()
( 283f70) pc: 1965c8 lr: 1e514c sp: 283f74 ^fetchcache_callback()
( 283f9c) pc: 1e5074 lr: 1db000 sp: 283fa0 ^fetch_done()
( 283fb8) pc: 1daf88 lr: 16dd14 sp: 283fbc fetch_poll()
( 283fc8) pc: 16dcf8 lr: 11891c sp: 283fcc ^netsurf_poll()
( 283fe0) pc: 1188d4 lr: a3914 sp: 283fe4 main()
( 283ff0) pc: a38f4 lr: ac1c sp: 283ff4 _main()
Register dump at 00283ff4:
a1: 0 a2: 1 a3: 7c0a2920 a4: 54207c0a
v1: 20736968 v2: 656c6966 v3: 74657320 v4: 70752073
v5: 72617620 v6: 73756f69 sl: 73797320 fp: 206d6574
ip: 69726176 sp: 656c6261 lr: 68772073 pc: 20686369
cpsr: a1a1a100
20686354 ANDEQ R0,R0,R0
20686358 ANDEQ R0,R0,R0
2068635c ANDEQ R0,R0,R0
20686360 ANDEQ R0,R0,R0
20686364 ANDEQ R0,R0,R0
20686368 ANDEQ R0,R0,R0
2068636c ANDEQ R0,R0,R0
20686370 ANDEQ R0,R0,R0
20686374 ANDEQ R0,R0,R0
Cheers,
Jan-Jaap
17 years, 10 months
[Netsurf-develop] Telnet?
by Joe Taylor
On my setup (current Netsurf), selecting an hyperlink which uses the
telnet protocol
(e.g. <A HREF="telnet://arcade.demon.co.uk">Arcade</A> )
causes Netsurf to show the hourglass but nothing happens and an escape
must be effected via Alt-break. Oregano, on the other hand, fetches and
runs 'Nettle' and the link is made without problem.
Cheers
Joe
--
mailto:joe_taylor@jettons.co.uk
AppBasic: http://www.jettons.co.uk/appbasic
17 years, 10 months
[Netsurf-develop] Animated GIFs, Frames and Scale View
by Tim Hill
build: 29 June 2005 00:00
I notice that anything other than 100% scale can result in animated GIFs
being plotted out of place, as well as the first GIF Frame where it
should be.
Example: <URL:http://www.sarva.co.uk/> (the 'roadworks' sign at the foot
of the page should appear only once).
I suspect this may be a Frames thing as I see the implementation is
experimental but scaling up seems to cause a large 'gutter' to appear
between the thin vertical left-hand menu frame and the main space; the
animated GIF appears in the gutter.
Of course, it is quite apt for this particular GIF to be in a gutter but
I thought someone should know. :-)
--
Tim Hill,
<URL:http://www.timil.com/>
17 years, 11 months
[Netsurf-develop] Locking up with select-drag
by Graham Pegg
For some time, there's been a strange problem which affects careless (!)
use of scrolling.
Holding select on a text area instead of blank space (not surprisingly)
initiates text select instead of scroll.
The problem arises when the pointer (with select still held down) crosses
from one piece of text to another (different text areas/tables or
something???). NetSurf locks with the hourglass running.
Alt-Break successfully exits NetSurf, and everything then behaves as normal
until the next 'accident' with text selection.
The end of the stderr file always seems to be similar to:
* Connection #0 to host www.naturodoc.com left intact
content/fetch.c fetch_stop 481: fetch 0x24ac4a58, url 'http://www.naturodoc.com/_themes/nd-theme2/nd_bkgrnd3.jpg'
* Closing connection #0
content/fetchcache.c fetchcache_callback 288: FETCH_FINISHED
content/content.c content_convert 539: content http://www.naturodoc.com/_themes/nd-theme2/nd_bkgrnd3.jpg
riscos/window.c ro_gui_window_click 1460: 4 1
riscos/window.c ro_gui_window_click 1460: 64 8
riscos/window.c ro_gui_window_click 1460: 4 1
riscos/window.c ro_gui_window_click 1460: 64 8
riscos/window.c ro_gui_window_click 1460: 4 1
riscos/window.c ro_gui_window_click 1460: 64 8
riscos/textselection.c gui_start_selection 50: starting text_selection drag
riscos/textselection.c gui_start_selection 87: xwimp_auto_scroll: 0x281: Invalid Wimp operation in this context
The part up to 'FETCH_FINISHED' and the following line are, I presume,
the conclusion of the page download (the problem isn't specific to any
particular sites AFAICS).
The 'riscos/window' lines are repeated different numbers of times (only
having pressed select once).
The final two lines always seem to be identical.
I'm running the build of 13 June (but this has been happening for some time)
on a SA RPC, RO3.7
Graham
--
+--------------------------------------------------------------------+
| Graham Pegg 'Uncle Greyboots' Dad(a)therpc.f9.co.uk |
| Using British Technology: Acorn RiscPC + StrongArm processor |
+--------------------------------------------------------------------+
A stitch in time would have confused Einstein
17 years, 11 months
Re: [Netsurf-develop] Slow down
by Adrian Lees
On Mon, 27 Jun 2005 you wrote:
> What's happened to the rendering speed?
>
> I just downloaded the 27 Jun 2005 02:00 build and immediately got the
> impression it was a lot slower than the one I used before (23 Jun 2005
> 18:15). It did a lot of 'hourglassing' during the 'Processing...' stage,
> while the previous versions only seemed to do that very briefly, just
> before going to 'Formatting...'.
It's a known problem induced by the latest version of UnixLib (a library
that NetSurf uses). We're looking into it. For now, if it's a problem
to you, then please use an earlier version.
> I'll admit that on my aging RPC with ARM 610 this will probably be more
> noticeable than on an Iyonix or a StrongARM machine, but still...
For some html, the slowdown can be quite noticable even on latest hardware,
so you can rest assured that it will be fixed ;)
Adrian
17 years, 11 months
[Netsurf-develop] Re: Running out of memory.
by David W Mills
[snip]
>
> Message: 3
> Date: Sun, 26 Jun 2005 15:46:18 +0100 (BST)
> From: John-Mark Bell <jmb202(a)ecs.soton.ac.uk>
> To: netsurf-develop(a)lists.sourceforge.net
> Subject: Re: [Netsurf-develop] Runing out of memeory
>
> On Sat, 25 Jun 2005, David W Mills wrote:
[snip]
> > I got a Netsurf is running out of memory message; When I clicked on a
>>Buy Now button
>
> This should have been fixed last night.
>
>
Yup!..... Took some time to load some images but not too long:-)
David
> John.
>
>
>
[snip]
--
17 years, 11 months
[Netsurf-develop] Slow down
by Frank de Bruijn
What's happened to the rendering speed?
I just downloaded the 27 Jun 2005 02:00 build and immediately got the
impression it was a lot slower than the one I used before (23 Jun 2005
18:15). It did a lot of 'hourglassing' during the 'Processing...' stage,
while the previous versions only seemed to do that very briefly, just
before going to 'Formatting...'.
So I did some testing [1] with both builds (and today's small build as
well) and on average the newer versions take about twice as long to
'finish' a page!
I'll admit that on my aging RPC with ARM 610 this will probably be more
noticeable than on an Iyonix or a StrongARM machine, but still...
Regards,
Frank
[1] One example: http://www.drobe.co.uk from launching the url to
'Document done':
23 Jun 2005 build: 50 seconds
27 Jun 2005 builds: 105 seconds
17 years, 11 months
[Netsurf-develop] Test Build (26 Jun 2005 22:30)
by Brian Howlett
Latest version doesn't load here - Test Build (26 Jun 2005 22:30).
Iyonix - RISC OS 5.09 - all updates applied. stderr as follows:
desktop/netsurf.c netsurf_init 68: version 'Test Build (26 Jun 2005
22:30)'
desktop/netsurf.c netsurf_init 75: NetSurf on <riscos>, node
<Iyonix.my.home>, release <5.09>, version <1.0>, machine <arm-acorn>
Error 0x80000204: Floating point exception: inexact operation
pc: 00117e60
Any ideas?
--
Brian Howlett
--------------------------------------------------------------
Windows has detected that the mouse has been moved.
You must restart Windows for the new setting to take effect...
17 years, 11 months
