Web links in Ovation Pro ?

Hi all.

Is it possible to create a PDF with web links from an Ovation Pro document?

I think this is the applet you need: https://gavincrawford.me/ovationpro/applets/urllink/

Thanks Andy, that’s part of the solution. But I do not think the links can be spreaded to a PDF file this way. PrintPDF?

As you’ve discovered, the URLlink applet only allows you to launch URLs to a browser (or via UniServer) that are written in the document text.

However, I do have another applet in development that allows URLs to be sent through to the PostScript output stream, that get converted into an active ‘hot-link’ region when distilled to PDF. My PDF workflow uses Adobe Acrobat/Distiller over on a PC to create my PDFs. I’ve not tested it on RISC OS Ghostscript/PrintPDF in a long time so can’t be sure if that works 100%.

The method I chose to implement it was also a bit odd as I needed to get it working quickly for my own needs, and I was looking for a method to integrate into existing OPro builds. I also started work on a more integrated system with it’s own object type and toolbar tools, that was ‘baked-in’ to the main OPro code, but at that time it was still closed source, so I didn’t proceed any further.

So the current version works as follows:
The applet interprets the loading of a URL filetype as if it is a graphic and the frame becomes a picture frame. When the URL picture frame is printed to a PostScript printer the applet converts the frame’s bounding box into the link’s active region on the page. The idea behind this method is that the visible text in the document doesn’t need to be a full URL, any text can be an active link, in fact, anything can – the link can be placed over a graphic, for example a social media icon.

It’s all a bit rough and ready at the moment and needs a lot of work before being ready for any sort of public release, but it is a work in progress.

I’ve not tested it on RISC OS Ghostscript/PrintPDF in a long time so can’t be sure if that works 100%.

It would be interesting to try… :-)

A long time ago, I tried to write a tool to create links from named styles in O-Pro: the idea was that an applet would generate a list of page coordinates from any text in a specific “link” style, which could be formatted up as PDFMark and passed on to PrintPDF. The idea stopped when it became apparent that there wasn’t (an easy?) way to extract absolute page coordinates of text objects using the script language. IIRC I asked on David Pilling’s mailing list, and got a fairly authoritative answer on that point.

I think PrintPDF still has the ability to chuck a PDFMark file at it during the PDF creation process, so there may be a way in through that if you have the details in the correct format. I haven’t used that in many years, however, so I can’t honestly say if it still works or not.

MeDDLe springs to mind. It allowed the creation of HTML with links from OPro. A special style was used to identify the links. Then the document was saved as DDL. Then the DDL was processed in MeDDLe to produce HTML.

It doesn’t solve this problem, but I wonder whether the approach offers something?

It would be interesting to try… :-)

The initial starting point for this applet was PDFinfo to inject document info into the PostScript stream and I seem to remember that it didn’t work with PrintPDF, possibly because it also uses the DOCINFO pdfmark operator to do similar. I haven’t tried it recently.

A long time ago, I tried to write a tool to create links from named styles in O-Pro

I’ve pondered for many hours over different ways to define the link regions. The problem with your method above, is how to handle the region if the text with the ‘link’ style wraps to the next line, or even over the page. The applet would have to create multiple rectangular regions to cope with this. Another issue is if the styled text doesn’t contain a URL, or if you actually want plain text to link to a URL.

So I went down the route of defining the link region using a frame and the frame contains a URL file. To be usable in a real document, the frame has to set to be transparent and no text flow runaround. In addition, I’ve recently added some extra script functions so I can select text and obtain exact page coordinates, then set the link frame to precisely cover the selected text. Obviously, if the document text gets edited the link frame’s position would possibly need to be adjusted. I’ve been toying with the idea of using OPro bookmarks to provide an anchor point so the link frame can be repositioned automatically before printing.

Ideally, all this would be better if it was implemented internally within OPro with new object types and tool(s) to provide a better user interface – but that is for another day.

To follow up on my previous post. I’ve tested it with PrintPDF and the URL links and Document info work correctly, but the PDF bookmarks are not working correctly for some reason. The bookmark titles are showing in Acrobat’s sidebar but the links to the named destinations don’t work. It’s something I’ll have to look into as they work fine when the same PostScript file is distilled using Adobe Distiller.

Replying to @Alan
Unfortunately, the MeDDLe approach doesn’t help here, as there is no way of knowing from the DDL where a particular piece of text would appear on the page (or even which page, if it happens to flow across many frames/pages).

It would be very easy to provide functions that return the coordinates of things on the page. If that simple thing would help a lot.

I am not up to speed on this – but the proper solution would be to have a new text/style attribute which was a link – you’d then have to say how links were printed.

There is spare space in style definitions, but only to hold a reference to the larger variable size space links need, it would all be a bit like tab rulers.

There is also the issue of compatibility with older versions of the program, probly one could arrange things so the old versions didn’t see anything.

After 30 years (in the mainstream) hypertext links are here to stay and some of the precious spare bits should be spent on them.

After 30 years (in the mainstream) hypertext links are here to stay and some of the precious spare bits should be spent on them.

I agree. And I think a few people do not use Ovation Pro for their production because it can’t support this. I do :)

What I would find useful would be a way to embed links to other parts of the document. That way…

For more information on tweaking your environment, please refer to the section on Configuring Reality on page 104.

…the link will go to the appropriate place.

[better yet if they can be flexible markers that move with the flow of the document so the correct destination page is shown automatically.]

[better yet if they can be flexible markers that move with the flow of the document so the correct destination page is shown automatically.]

How would links work, at the moment, click in the text to position the caret. So to go to a link (?) Shift key modifier plus click, or a read only mode.

OP documents do have bookmarks, markers in the text that go with the flow, people have used them for all sort of things.

I was thinking about embedded links in PDF files, that’s arguably the most useful place for them to work.

Having said that, I can envisage something like a Shift-click to follow a link in the document within OPro could be useful for navigation as well.

It sounds as if the bookmarks are a good basis. I don’t know what is actually required to get in-document links working with PDFs.

Hmm, can PS2/PrintPDF/GhostScript even do this sort of thing? Some googling found this, but it’s gibberish to me, I don’t speak PostScript. https://stackoverflow.com/questions/57457884/postscript-preserve-internal-hyperlinks-in-pdf

Hmm, can PS2/PrintPDF/GhostScript even do this sort of thing?

From earlier in this thread: https://www.riscosopen.org/forum/forums/5/topics/19123?page=1#posts-147937

Gavin Crawford (see his post above) is the expert in links in PDF and OPro documents.
OP has loads of explicit code for all the possible attributes of text. Like bold, italics, superscript… there are dozens of attributes and the code is lots of if(bold)… if(italic)… and so on. Their behaviour is the same.

If I was going to do anything I would allow general attributes to be added. One of them can be hypertext links. They could be anything anyone wanted to invent.

I would have done it this way originally, but in 1992 saving every bit mattered, does not look so clever in 2024. “Hey look my program only uses 1 bit to signify bold text”. “What? this web page uses 123MB (in Chrome) – not possible, computers can only have 4MB”.

Probly remind me next Winter when I have nothing else to do.

What? this web page uses 123MB (in Chrome)

Yes, it’s incredible how much cache crap Chrome creates (oh, the alliteration).

my program only uses 1 bit to signify bold text

I can’t help but think that if you need more than one flag to say something is or isn’t bold, you might be doing it wrong…unless the typesetting system provides degrees of boldness, but that’s not an issue here. Get a bunch of these flags together, that’s a text style, right? Seems logical enough, and won’t bloat the document with unnecessary rubbish.

RISC OS out of the box did not support bold/italic, just font names. Takes Computer Concepts (or maybe Acorn DTP) to come along and introduce four font family members, normal, bold, italic and bold/italic – you can then use one bit for bold and another for italic.

However there is no end of sorrow when people port fonts from other systems with many more than four members – degrees of boldness. OPro then has to synthesise font families to make all the variations available.

Seems there isn’t really any standardisation of the names.

There’s some code in Tea to determine what the desktop font is, and then create other sizes (plus a bold version) for a better looking result that fits in with the desktop look and feel.

So most have .Medium → .Bold as the heavy type suffix.
Some are .Medium → .Demi.
One breaks this with Sassoon.Primary and Sassoon.Primary.Bold (so Bold is added, Primary is not replaced).
Some don’t have bold and some don’t have weights.

I don’t envy you the job of trying to work out that mess in a DTP program. Is it Bold.Italic? Is it Demi.Oblique? Or are there both and they aren’t the same? Etc etc etc.

I’ve been using RISC OS professionally for DTP for 30 years, and 28 of those using Ovation Pro. When using Bold and Italic variants I always set up a style using the appropriate front name, and never use the font effects. That way if the document changes the base font you don’t get strange font changes for bold and italic if the new font doesn’t have the same naming convention. You can just change the style.
Just a Tip!

Rick – you could find the ‘algorithm’ OP uses to categorise fonts in the sources – grep for Demi – but I got a lot of criticism over it.

I suspect my story above about synthesising fonts is thinking about Ovation, and not Ovation Pro, I am surprised to find individual font names can be picked in OP (thanks Gavin), but it still seems to pick another name if bold etc is selected.

Pick an individual font member in the style edit window and it ticks the bold/italic flags as it sees appropriate.

Probably it is proof against system changes – I had four font family members and now I have eight, which changes how bold/italic would be set up.

I just found that selecting italic picks a bold font because there is only Roboto.Black.Italic (base Roboto.Light, add italics, get Roboto.Black.Italic). Roboto seems to come with RPCEmu and contains 12 members – (“strange font changes”) – might be a good example for experiments.

Interesting discussion, as ever things are more complicated than you might imagine, compromises have to be made, but getting away from hyperlinks.

The latest trend is variable fonts, where there are several “axes” for different aspects of the font that can be changed; weight is the commonest of these, although there are others, including “slant” and “optical width”. Support for these has recently been introduced in Affinity Publisher on Mac and PC: see here: https://youtu.be/uD96Cau8T4k?si=9UG8yaeskmeEpXfS

variable fonts

Very interesting. OP supports a skew value setting for text, a bit like variable italics.

The latest trend is variable fonts, where there are several “axes” for different aspects of the font that can be changed; weight is the commonest of these, although there are others, including “slant” and “optical width”.

Philip’s Music Scribe (later Philip’s Music Writer) has a similar concept it calls “shearing angle” which is specified in degrees. This is in addition to a stretching factor, the width/height ratio.

This, along with point size, allows a single font to offer many different appearances for different purposes in a musical score using just 3 numerical parameters.

This is described succinctly on page 55 of the PMW manual supplied with PMS, available via PackMan. That manual is copyright 2005, and the implementation well pre-dates that.

As David points out, Ovation Pro does have a skew value that can be used to give a very different look to a font face. You can see an example of it at the bottom of the page on my example Drop Shadows page.

my example Drop Shadows page.

Wow. That looks abysmal in (Android) Chrome in dark mode.
You’d have thought, maybe just maybe that there would be some logic to say “if the background is nearly white then don’t invert the text to be white”, wouldn’t you?
But, alas, I fear that the mighty Google coders are too busy trying to think of exciting new ways to track us and pillage the wreckage of what once was our privacy that all the other “features” have been assigned to the work experience kid.

a bit like variable italics.

The insufferable pedant in me wishes to point out that oblique and italics are not the same thing. There is a difference (and it’s not just that oblique is a fancy word for italics).

Oblique is a tilted version of the primary type style. That is to say, if you untilt text in oblique, the result should exactly look like the regular text.
Italics, on the other hand, are a slanted version of the primary style that has a separate and individual design for each letter; which means the untilting them will not result in something that looks like the regular text.

You can easily see this with Trinity. Open OvationPro and write out something with a selection of letters. For my example, I wrote out the meaning of the acronym “WTF?”.
Write it out twice, set them both to something you can see details clearly (like 36pt).
The first time, Trinity.Medium with a skew of 15%. The second time, Trinity.Medium.Italics.

Notice the curly tail on the ‘h’, the completely different ‘a’, the much curvier ‘e’, the big descender on the ‘f’, along with curly tails on the ‘u’ and ‘k’ and the fact that the italicised letters look lighter.

Now, if you have it, switch to the Ladybird font and its oblique version. You’ll see that this is, correctly, oblique as there is no discernable difference between the two. You can set the regular to 0° skew and the oblique to -15° and they’ll both look alike.