I have a collection of single-page music scores that are in the form of a
PDF file with a useless (as in non-linked) index and some extraneous pages.

Unfortunately RISC OS cannot display these pages correctly as most of them
use embedded fonts, but as I am merely using this to process them for use
on a(n Android) tablet, that doesn't matter much.

The first thing I have done is to split them into separate pages using
PDFtools, a front-end to the ported Xpdf utilities by Derek Noonburg, then
renamed the individual files more sensibly. Now at least I can identify
them under a filer!

What I want to do is to create a page to access these files quickly and
effectively.

My first attempt was to create a simple HTML page with links to each page,
all contained within a single directory to avoid path problems.

This "worked" under RISC OS insofar as a selected link would offer a
download of the chosen PDF file. This was because the RISC OS browser
could not natively load the files itself, and was only to be expected.
However, modern browsers on the tablet can display them, which was the
behaviour and context I was aiming for.

However, on transferring this folder to Android, the simple "have them all
in the same directory" approach failed as, for some mysterious reason, the
HTML index file "thought" it was in a remote sub-directory of the folder.
It did not seem practical to remedy this, so I moved on.

Next I thought of my faithful TechWriter. I loaded the index file I had
created into it, and resaved it as a PDF file. I get a page of links just
like in the HTML version.

Examining each, they appear to be names corresponding to a filename
(leafname) as expected: "02 Rattling Bog, The Sloe" does indeed show under
"Misc>Link" as the file "RattlingBog.pdf", but does not, when clicked,
attempt a download like the original HTML did under RO, and similarly did
nothing under Android, not even an error.

My next thought was creating a PDF index page using page numbers, and using
this as the first page of a "reconstituted" PDF multipage document.

But I can't see in either TechWriter or Print PDF how to do this. Both
have extensive internal referencing/bookmarking functions, but I can't see
a simple "go to page n" function. When considering this, remember that I
don't want to reprocess the individual pages under RO, as I might lose
unrecognised embedded content, I just need an effective indexing method for
existing pages that works under Android.

Any ideas or clarifications to offer?

John

On 26/10/2023 10:57, John Williams (News) wrote:
<snip>

I just need an effective indexing method for
> existing pages that works under Android.
>
> Any ideas or clarifications to offer?
>
> John
>

Having not seen any html code of other specifics of the android setup,
it's hard to say for sure but I guess your parent document is being
opened in some temporary cache type area and that is where it's looking
for the child 'pdf' document. Which wont be there.

Example, content://media/external/file/whatever.pdf

I assume you are _not_ running your own web server on the android
device? You could use the absolute filename to the pdf files in your
html code or run a web server on the device to get full control.

Mike.
--

In article <653a386b$0$25961$426a34cc@news.free.fr>,
John Williams (News) <UCEbin@tiscali.co.uk> wrote:

> Any ideas or clarifications to offer?

It's probably a curse in a church (Dutch expression), but what about
forgetting RISC OS completely and download MobileSheet on your Android
tablet. It does everything you ask for, plus a thousand things more.
Indispensable for musicians.

Paul

--
https://riscos.sprie.nl

On 26 Oct 2023 as I do recall,
John Williams (News) wrote:

>
> I have a collection of single-page music scores that are in the form of a
> PDF file with a useless (as in non-linked) index and some extraneous pages.
>
> Unfortunately RISC OS cannot display these pages correctly as most of them
> use embedded fonts,

I find that the Bitmap mode in my copy of !PDF can generally display
embedded music fonts correctly - it just takes much longer to render
each page as a bitmap than to map the fonts to their native equivalents.

> but as I am merely using this to process them for use on a(n Android)
> tablet, that doesn't matter much.
>
> The first thing I have done is to split them into separate pages using
> PDFtools, a front-end to the ported Xpdf utilities by Derek Noonburg, then
> renamed the individual files more sensibly. Now at least I can identify
> them under a filer!
>
> What I want to do is to create a page to access these files quickly and
> effectively.
>
>
> My first attempt was to create a simple HTML page with links to each page,
> all contained within a single directory to avoid path problems.
>
> This "worked" under RISC OS insofar as a selected link would offer a
> download of the chosen PDF file. This was because the RISC OS browser
> could not natively load the files itself, and was only to be expected.
> However, modern browsers on the tablet can display them, which was the
> behaviour and context I was aiming for.
>
> However, on transferring this folder to Android, the simple "have them all
> in the same directory" approach failed as, for some mysterious reason, the
> HTML index file "thought" it was in a remote sub-directory of the folder.
> It did not seem practical to remedy this, so I moved on.

What was the displayed URL of the index file?

Can you hardwire the links to an absolute path on your tablet rather
than a relative one?

--
Harriet Bazley == Loyaulte me lie ==

Whenever I feel like exercise, I lie down until the feeling goes away.

In article <7c6284f95a.harriet@bazleyfamily.co.uk>,
Harriet Bazley <harriet@bazleyfamily.co.uk> wrote:

> What was the displayed URL of the index file?

> Can you hardwire the links to an absolute path on your tablet rather
> than a relative one?

The path was too long to display fully in the Chrome URL bar, and my
expertise in Android is somewhat limited and, I expect off-topic for this
group.

Barring a miracle, I expect I'm going to end-up using the Android filer and
improving my file-naming!

I also think I'm misunderstanding a lot about the nature of the indexing
used in the two apps.

I would just like to achieve an end for my fellow group members about which
I can feel proud, not least of my minority OS which can often achieve
superb results with a minimum of effort and complication.

Thank you for your interest and response.

Best wishes,
John