Ticket #160 (Fixed)Sun Dec 02 20:43:48 UTC 2007

Please could you attach the page in question, in a Zip file, by adding a comment to this ticket? Alternatively, please could you provide a URL to the page in question on a live web site?

The Aemulor result is probably a result of it doing something odd like restricting all applications (rather than just 26-bit apps) to a 28MB Wimp slot, to emulate a limit in older versions of RISC OS. I don’t know if RISC OS 4 or 6 variants have this same limit, but given the result you got in VRPC it seems likely that, sadly, they do. RISC OS 5 has a much greater per-application slot limit so your only option would be the Iyonix.

It would be useful to find out just why so much memory is being consumed in the first place, though, as well as figure out why the rendering errors result. It does sound like there’s particularly complex / heinous HTML being involved since the rendering time is huge, the slot size required is huge, and “File too big” almost certainly means that the PDF generated from that HTML is exceeding the file size limit of your filesystem type (probably 2GB!). This analysis will be impossible without a copy of the page to work from.

Agree Iyonix only option. Using Adobe Acrobat and IE7 (yuk!) it consumes about 360Mbytes (as viewed in the printer status window) when creating the pdf [but of course no links!] but of this only about 80Mbytes is relevant as the rest is the summated image sizes and the sub directory with the images is hidden on Iyonix so no space is required for these.
The HTM file includes 300 A4 pages of which about 100 pages comprise a single table and there are about ten thousand NAME/HREF internal links. Although there is css present (I haven’t yet moved this into the tags) I assume Pheonix ignores this. Only if I can get it to work will I spend the time doing this.

Possibility that Pheonix assumes a 32M or 64M application space? The table shows lines which clearly relate to other tables/images/parts of the table being displayed, as well as those that are correct, but the text appears as expected, just a forest of extra horizontal lines.

Attachment (447k) contains the HTM file (4M) and the pdf file (16k) reated before it aborted.

for ‘[ minutes]’ on original post please read ‘[35 minutes]’

Mea culpa. It works better with HTML that is not broken (a few </tr> tags were without the ‘/’). Attachment now has (more) valid HTML – uses 53M workspace, (6389k in status bar) and takes 40 minutes to load the page.

Loading the images (which are not included in the attachment) takes the status bar up to 18.24M.

Creating the pdf files takes a while (just over an hour) and they end up a bit larger than the Adobe Acrobat equivalent (285M rather than 55M). Would be nice if there was more control of fonts (e.g. <font face=“Homerton”>..</font>) as the ‘Choices’ only allows three fonts (heading body and fixed) and I really need four … .

Sorry to report a bug that wasn’t!

I have not had time to look at the HTML yet so haven’t spent time on the broken HTML version.

With the speed of RISC OS hardware and its typical RAM allocation – even in an Iyonix – rendering such large pages is always going to be slow. Firefox on my PC takes a long enough time as it is….

RISC OS has limits on the coordinate system used for plotting to the screen. Extremely tall tables can exceed this limit particularly for external borders, so if you notice lines going upwards off the top of the page when you expected them to go downwards, then this is the reason. However, looking briefly at your HTML now, it seems to already split the page up into a series of tables, rather than one huge one, so this shouldn’t be a problem.

Image export in PDF output is quite slow so this may be holding you up. The browser also outputs “human-readable” PDF, for those who know the document structure, with images only ZLib compressed (lossless) rather than using JPEG. Adobe Acrobat tends to compress the non-image data stream too which is why the file size is smaller, though you’ve also lost information when using that route too – no links. If you were to put your PDF file into a Zip archive (though this would take a very long time – using the Zip command line tool from a Task Window would be a better option than SparkFS) you should see a huge drop in file size.

Thanks for your time – actually it contains one table that extends over 300 A4 pages with three columns, even pages using a COLSPAN of the middle column and the thin right column for content (sometimes another nested table) and the thin left column for a page-height blank image (gutter). Odd vv. The big table has no border so perhaps avoids the problem you state.

The <font face=“Homerton eg”> tag or another criterion for use of a different font than Headers/Body/Fixed would be useful.

I hadn’t noticed the TABLE tag hiding away at the start of the page.

Doing this in one huge 4MB table is not the ideal…! No wonder it takes so long to render even on a fast PC. Each time the browser fetches a bit more data at the bottom of the HTML file, it has to lay out the entire outer table from top to bottom again. It must repeatedly reformat the whole huge document as it grows, over and over again, because the width of any part of the table further down can influence the width of parts of the table higher up.

Since the output is designed to be paginated, especially given that it seems to expect left/right facing pages, it probably doesn’t matter if the columns on one page aren’t exactly the same width as the columns on the next, assuming that you can’t force the browser into keeping a certain width in some way. Indeed, keeping things in independent tables might increase your chances of making successive tables’ column widths match, because there will no longer be rendering side-effects introduced by other parts of the outermost table.

Ultimately, I recommend that you try splitting things into smaller tables as you’ll probably get much lower RAM requirements and much faster rendering on any platform.