Re: regexec
by John-Mark Bell
On Thu, 31 Jul 2008, Chris Young wrote:
> On Thu, 31 Jul 2008 18:33:31 +0100 (BST), John-Mark Bell wrote:
>
>> All paths passed up from the core will be in Unix format (as it basically
>> just strips the scheme + authority off the front). Thus, fetch_filetype()
>> should be expecting a Unix path.
>
> So it does (I just copied the debug code for this routine without
> looking at it). I can fix that at my end then, but that doesn't help
> if the path is wrong when fetching files.
Actually, what I wrote above isn't entirely accurate. The core simply
passes around whatever you pass it, adding or stripping "file://" as
appropriate (Yes, two slashes -- the third is assumed to be the start of
the path segment, as per the URI spec).
> (I really, really, don't want to enable UNIX path compatibility, I'd
> rather work out a way to use native paths)
On RISC OS, our runtime library performs this conversion transparently.
Your alternative would be to implement a platform-specific handler for
file: URLs. Then you can do whatever you like.
See content/fetchers/fetch_*.c for existing fetch handlers. I think
there's also one in beos/, as that has some slightly different
requirements, too.
Overall, this seems far cleaner that changing NetSurf's core + the
underlying fetch library (cURL) to gain support for specific platforms).
J.
15 years, 1 month
GSoC Progress Report (July 31st)
by Mike Lester
This week I have been working on a redesign of the global history dialog. It
is now split into two lists, one of domains and another of the sites from
those domains. I added a search bar which filters both the sites and domains
as well as a combo box to choose sorting options. Unfortunately my network
card gave out earlier this week so I have been unable to commit these
changes but I should have a replacement soon.
Next week I plan on polishing up the history dialog and then moving on to
Bookmarks for the remainder of GSoC.
15 years, 1 month
Re: regexec
by John-Mark Bell
On Thu, 31 Jul 2008, Chris Young wrote:
> On Thu, 31 Jul 2008 00:01:25 +0100, Rob Kendrick wrote:
>
>> On 30 Jul 2008 23:44:20 +0100
>> "Chris Young" <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
>>
>>> I now have lots of work to do writing native code, currently it opens
>>> a window, fetches a page and sets the window's title - and then sits
>>> in an endless loop doing nothing, as that's as far as I got.
>>
>> If you want a Subversion account to check your current work in, please
>> ask. Checking in often and early is worthwhile; especially given we've
>> made quite large changes to the Make system recently.
>
> Yes please - that will be very useful. I'm working with an SVN
> snapshot at the moment and I can see it getting further and further
> behind.
Send us a username, and it'll be done. :)
> I can't see anything relevant in there. There is some code in
> fetch_curl.c which handles the filetypes:
>
> if (strncmp(f->url, "file:///", 8) == 0)
> url_path = curl_unescape(f->url + 7,
> (int) strlen(f->url) - 7);
>
> Changing the two 7s to 8s here appears to send the correct path to
> the local MIME type routine.
Aha. No. :)
All paths passed up from the core will be in Unix format (as it basically
just strips the scheme + authority off the front). Thus, fetch_filetype()
should be expecting a Unix path.
> I'm told that file:/// is correct (and there is certainly code
> elsewhere which converts file:// to file:///), but path_to_url in
> urldb.c only adds two?
That's because the urldb builds a unix-format path, so the third slash is
provided by the tree traversal code. Note that that code is simply a test
stub, anyway.
> I think I probably need an #ifdef in the code which picks out the path
> from the URL, so it starts at the eighth character instead of the
> seventh. Maybe this can be a global variable or defined in
> utils/config.h, as I can see it being a problem for other platforms as
> well (eg. Windows).
I really don't like this idea. Platform-specific ifdefs in the core code
suck -- we're trying to phase any remaining ones out.
J.
15 years, 1 month
Re: regexec
by Chris Young
On Thu, 31 Jul 2008 00:01:25 +0100, Rob Kendrick wrote:
> On 30 Jul 2008 23:44:20 +0100
> "Chris Young" <chris.young(a)unsatisfactorysoftware.co.uk> wrote:
>
> > I now have lots of work to do writing native code, currently it opens
> > a window, fetches a page and sets the window's title - and then sits
> > in an endless loop doing nothing, as that's as far as I got.
>
> If you want a Subversion account to check your current work in, please
> ask. Checking in often and early is worthwhile; especially given we've
> made quite large changes to the Make system recently.
Yes please - that will be very useful. I'm working with an SVN
snapshot at the moment and I can see it getting further and further
behind.
> > btw, file: URLs seem to be adding a slash to the beginning of the
> > path, no matter how I specify them. This is very annoying, as a slash
> > at the start of a path indicates the parent of the current directory.
>
> Ah, that may be a bad assumption on my part. All the /sensible/ OSes
> treat multiple contiguous slashes as a single one. :)
But then you miss out on the fun of ram:t//clipboards/0 etc ;)
I also don't see why this wasn't a problem for RISC OS, last time I
checked a slash was a valid filename character rather than a path
separator, so I would expect it to complain profusely if this was
present at the start of a fully-qualified path.
> You'll want to examine the content of content/fetchers/fetch_data.c
I can't see anything relevant in there. There is some code in
fetch_curl.c which handles the filetypes:
if (strncmp(f->url, "file:///", 8) == 0)
url_path = curl_unescape(f->url + 7,
(int) strlen(f->url) - 7);
Changing the two 7s to 8s here appears to send the correct path to
the local MIME type routine.
I assume exactly the same code is elsewhere but I can't find it.
I'm told that file:/// is correct (and there is certainly code
elsewhere which converts file:// to file:///), but path_to_url in
urldb.c only adds two?
I think I probably need an #ifdef in the code which picks out the path
from the URL, so it starts at the eighth character instead of the
seventh. Maybe this can be a global variable or defined in
utils/config.h, as I can see it being a problem for other platforms as
well (eg. Windows).
Chris
15 years, 1 month
Re: regexec
by John-Mark Bell
On Wed, 30 Jul 2008, Chris Young wrote:
> On Thu, 24 Jul 2008 23:05:01 +0100, Rob Kendrick wrote:
>
>> The defines enable the features of the C library that we require on
>> various operating systems. On *BSD libc, glibc and Solaris, you need
>> this collection of #defines to enable modern library functionality.
>> It surprises me that these matter, as if your C library triggers on
>> them, the only sensible thing it could do is enable more
>> functionality. This may point to an issue in the C library on your
>> host system. Try removing one at a time to see if it's just a specific
>> one that causes the issue, and then grep your standard headers to see
>> what triggers on it.
>
> I put them all back and can't reproduce the problem again, although
> strncasecmp is still crashing.
Make sure you've got no compiler warnings along the lines of:
warning: implicit declaration of function 'strncasecmp'
> btw, file: URLs seem to be adding a slash to the beginning of the
> path, no matter how I specify them. This is very annoying, as a slash
> at the start of a path indicates the parent of the current directory.
>
> file://default.css will translate to /default.css which looks in the
> parent directory for the file default.css.
The correct form for file: URLs (and what NetSurf uses internally) is
file:///path/to/file. It /should/ leave the path part alone if there's the
right number of slashes at the start. If it doesn't, then that's something
that needs investigating.
J.
15 years, 1 month
Re: regexec
by John-Mark Bell
On Wed, 23 Jul 2008, Chris Young wrote:
> On Tue, 22 Jul 2008 19:37:52 +0100 (BST), John-Mark Bell wrote:
>
>> I'm not sure I have any recollection of it being solved, tbh. None of us
>> have been able to reproduce it, so it's somewhat difficult to work out
>> what's happening.
>
> Well, I fixed it, but I'm not entirely sure how. I deleted a load of
> defines from the makefile (ones I had initially copied from the debug
> target and then forgotten about) and just recompiled it again from
> scratch.
It'd be really useful if we could work out what's causing this, so we know
for the future. Do you know which defines you removed?
J.
15 years, 1 month
GSoC Report
by Adam Blokus
This week I was trying to implement Unicode support to libharu. Even
though I have spent a lot of time on studying Haru code and the PDF
reference I kept getting errors.
Because the trouble could be solved by someone from Haru in a much
shorter time I won't spend any of mine any more on this task until I
get some response from the devs.
To have at least this done, I have added the Export tab to the gtk
options. I had some doubts whether some of them (or maybe all so that
everything would be in one place) should get in a separate dialog
showing up each time an export to pdf is performed. I am waiting for
your comments :)
Adam
15 years, 1 month
GSoC Report
by Adam Blokus
> I like the progress so far. It would be good to work on improving the
> output so it works better with more PDF viewers, I think.
I will take care of the smaller changes this week and of the bigger
ones in the following weeks as they are planned for debugging.
Also, I got a response from Haru so I think Unicode can be moved
forward in that time too.
15 years, 1 month
Re: Making knockout plotting optional
by John-Mark Bell
On Wed, 30 Jul 2008, John Tytgat wrote:
> I'm seeking feedback on my changes to make the knockout plotting optional
> based on the plotter backend (patch attached). I've added a new entry
> 'option_knockout' to 'struct plotter_table' which basically is a request
> from that plotter backend for the content redraw routine to get called in
> such a way that overlapping render areas are avoided as much as possible
> (that's what I'm assuming the knockout.c code is doing).
This looks fine to me.
> However, it is up to the content redraw code to actually implement this
> option if it is reasonably profitable. This was and is currently done
> explicitly by the html content redraw code. On top of that the riscos
> plotter code was installing the knockout plotter itself for all content
> types except plaintext and SVG and this is no longer being done in this
> patch.
This seems cleaner, yes. I have a suspicion that the RO code manipulating
the knockout plotter is legacy that can be removed. Certainly, the
content-specific redraw routines are far more likely to know whether
knockout's required.
> In patch more detail:
>
> - desktop/plotters.h: added struct plotter_table::option_knockout
> - render/html_redraw.c(html_redraw): if the plotter backend wants the
> knockout calling behaviour, install the knockout plotter which will then
> call the real backend. Also check on the return values of clg and clip
> plotter calls.
> - Plotter backend changes:
> -> no longer plotting in knockout mode:
> - gtk/gtk_print.c: BTW, also removed what I think is a 2nd instance
> of "struct plotter_table plot" (the first one is in
> gtk/gtk_plotters.c), right ?
It looks that way, yes.
> - riscos/window.c: I'm a bit confused why there were tests on the
> content type which determine to additionally install the
> knockout plotter in front of the real plotter code as as far as
> I believe that only HTML content is profitable to be plotted
> in knockout mode, no ?
Yeah. Everything else is basically flat objects, so wouldn't benefit from
knockout.
J.
15 years, 1 month
Making knockout plotting optional
by John Tytgat
I'm seeking feedback on my changes to make the knockout plotting optional
based on the plotter backend (patch attached). I've added a new entry
'option_knockout' to 'struct plotter_table' which basically is a request
from that plotter backend for the content redraw routine to get called in
such a way that overlapping render areas are avoided as much as possible
(that's what I'm assuming the knockout.c code is doing).
However, it is up to the content redraw code to actually implement this
option if it is reasonably profitable. This was and is currently done
explicitly by the html content redraw code. On top of that the riscos
plotter code was installing the knockout plotter itself for all content
types except plaintext and SVG and this is no longer being done in this
patch.
In patch more detail:
- desktop/plotters.h: added struct plotter_table::option_knockout
- render/html_redraw.c(html_redraw): if the plotter backend wants the
knockout calling behaviour, install the knockout plotter which will then
call the real backend. Also check on the return values of clg and clip
plotter calls.
- Plotter backend changes:
-> no longer plotting in knockout mode:
- gtk/gtk_print.c: BTW, also removed what I think is a 2nd instance
of "struct plotter_table plot" (the first one is in
gtk/gtk_plotters.c), right ?
- riscos/save_draw.c
- riscos/print.c: in addition I noticed that the path plotter
function pointer wasn't filled in and this is now fixed.
- pdf/pdf_plotters.c: I also removed the flush function as this is
optional and we only had a dummy implementation there.
-> remaining to request knockout mode if it makes sense based on the
content type:
- gtk/gtk_plotters.c: but I guess this needs testing by the GTK
developers if this remains a good choice or not.
- riscos/plotters.c
- desktop/knockout.c: I believe its option_knockout needs to be
'true' because knockout_plot_start/knockout_plot_end needs to
be called for each recursive html_redraw() call.
- riscos/window.c: I'm a bit confused why there were tests on the
content type which determine to additionally install the
knockout plotter in front of the real plotter code as as far as
I believe that only HTML content is profitable to be plotted
in knockout mode, no ?
Does this change make sense ? Anything which I'm overlooking here ?
John.
--
John Tytgat
joty(a)netsurf-browser.org
15 years, 1 month
