Re: [Rpcemu] New 0.9.2 Mac binary release

Brilliant, many thanks Kevin! That is great. I'll try it out straight away.

Today I had a lot of fun going through my old hard drive. It has been a real trip down memory lane. Chocks Away runs blazingly fast in the emulator, I don't suppose there is a way to slow down the rpcemu emulation? Not to worry if there isn't. I've been using the interpreter version of rpcemu.

Many thanks to everyone and sorry for the endless emails!

Pete

Get BlueMail for Android

On 28 Apr 2020, at 15:47, Kevin Wells <kev@kevsoft.co.uk> wrote:

In message <3780079B-2942-417C-8767-298B5C473EE0@gmx.net>
          Peter Moore <petemoore@gmx.net> wrote:


I don't suppose the emulator has a feature to emulate the presence of the Impressions Publisher dongle, so I can open up my old documents? That is the only real issue I have left to solve...
Impression Style is now a free download thanks to RISC OS Developements
from the PlingStore

<http://www.plingstore.org.uk/cgi-bin/plingstore/download.cgi>

Re: [Rpcemu] New 0.9.2 Mac binary release

In message <3780079B-2942-417C-8767-298B5C473EE0@gmx.net>
Peter Moore <petemoore@gmx.net> wrote:

>
>I don't suppose the emulator has a feature to emulate the presence of the Impressions Publisher dongle, so I can open up my old documents? That is the only real issue I have left to solve...
>
Impression Style is now a free download thanks to RISC OS Developements
from the PlingStore

<http://www.plingstore.org.uk/cgi-bin/plingstore/download.cgi>

--
Kev Wells
http://kevsoft.co.uk/ https://ko-fi.com/kevsoft
carpe cervisium
There is no such thing as public money; there is only taxpayers' money.

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] New 0.9.2 Mac binary release

Many thanks Tim!

You resolved my issues! Indeed, I had several installations of RPCEmu and this was from the wrong installation. After cleaning up, and finding the correct directory, I was able to get things running with a blank harddisk image (to make sure I was editing the correct hd4.hdf file) and then after prepending my own hard disk image with 512 zero bytes, I had my old machine running in the emulator! Amazing.

I have a couple of warnings that I suspect I probably also had on the old machine, but most things seem to work. The drive is full of my old BASIC programs, whose purpose/function mostly elude me now, but I'm looking forward to rediscovering them. :-)

I don't suppose the emulator has a feature to emulate the presence of the Impressions Publisher dongle, so I can open up my old documents? That is the only real issue I have left to solve...

Great to have the HostFS integration to extract files from the hard drive, I'm impressed, both with the old RISC OS for having a mechanism to recognise/discover pluggable file systems, and RPCEmu for being able to present a virtual filesystem to RISC OS. A very nice tight integration. :-)

Pete

On 27. Apr 2020, at 21:05, Timothy Coltman <lists@maemagel.com> wrote:

On 27 Apr 2020, at 19:42, Peter Moore <petemoore@gmx.net> wrote:

Hi guys!

I installed the new RPCEmu, and managed to dump an image of my RISC PC 600 hard drive using `dd` on linux.

I copied the raw hard disk image to the RPCEmuDataDir as hd4.hdf and have RISC OS 3.60 roms in place.

I followed the instructions on https://www.marutan.net/rpcemu/manual/#hdf but when i run the first command I get the following error:

<Screenshot 2020-04-27 at 20.33.10.png>

RISC OS 24MB

Supervisor

*dir aufs::4.$

Disc drive not known (Error number &108AC)

*

Strange - your boot messages don't include ADFS.  Is your CMOS corrupted? I'd try copying the one from my recent Mac release, as that's the one supplied with the source, so should contain some sensible defaults.  If that doesn't work, check to see if the module is unplugged (*RomModules).

Incidentally, which release are you using?  The "plist" file you included looks like one of Francis Devereux's from the 0.8.x versions (judging from the file name).

Does the raw device file produced by dd need to be altered in any way for it to work?

It looks like it (Sarah is the original author of RPCEmu):

https://stardot.org.uk/forums/viewtopic.php?t=18291#p254144

There are some instructions here:

http://www.riscos.info/pipermail/rpcemu/2011-March/001261.html

Tim

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] New 0.9.2 Mac binary release

On 27 Apr 2020, at 19:42, Peter Moore <petemoore@gmx.net> wrote:

Hi guys!

I installed the new RPCEmu, and managed to dump an image of my RISC PC 600 hard drive using `dd` on linux.

I copied the raw hard disk image to the RPCEmuDataDir as hd4.hdf and have RISC OS 3.60 roms in place.

I followed the instructions on https://www.marutan.net/rpcemu/manual/#hdf but when i run the first command I get the following error:

<Screenshot 2020-04-27 at 20.33.10.png>

RISC OS 24MB

Supervisor

*dir aufs::4.$

Disc drive not known (Error number &108AC)

*

Strange - your boot messages don't include ADFS.  Is your CMOS corrupted? I'd try copying the one from my recent Mac release, as that's the one supplied with the source, so should contain some sensible defaults.  If that doesn't work, check to see if the module is unplugged (*RomModules).

Incidentally, which release are you using?  The "plist" file you included looks like one of Francis Devereux's from the 0.8.x versions (judging from the file name).

Does the raw device file produced by dd need to be altered in any way for it to work?

It looks like it (Sarah is the original author of RPCEmu):

https://stardot.org.uk/forums/viewtopic.php?t=18291#p254144

There are some instructions here:

http://www.riscos.info/pipermail/rpcemu/2011-March/001261.html

Tim

Re: [gccsdk] PDFUtils adding .etctension

In article <654fd36758.Kevin@talktalk.net>,
Kevin Wells <kev@kevsoft.co.uk> wrote:

> Thanks have downloaded the new versiona and am using it. Is their plans
> to put the new version on here so that one version is in use?
>

That's the intention. Hopefully it will appear in PackMan soon.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [Rpcemu] New 0.9.2 Mac binary release

I should add, the disk I imaged was the original RISC PC disk which was a Conner CFS420A (https://www.computerhope.com/hdd/hdd0020.htm) with 63 sectors and 16 heads as required….

On 27. Apr 2020, at 20:42, Peter Moore <petemoore@gmx.net> wrote:

Hi guys!

I installed the new RPCEmu, and managed to dump an image of my RISC PC 600 hard drive using `dd` on linux.

I copied the raw hard disk image to the RPCEmuDataDir as hd4.hdf and have RISC OS 3.60 roms in place.

I followed the instructions on https://www.marutan.net/rpcemu/manual/#hdf but when i run the first command I get the following error:

<Screenshot 2020-04-27 at 20.33.10.png>

RISC OS 24MB

Supervisor

*dir aufs::4.$

Disc drive not known (Error number &108AC)

*

My setup looks like this:

pmoore@Petes-iMac:~ $ cat ~/Library/Preferences/org.devrx.RPCEmu.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>NSNavLastRootDirectory</key>

<string>~/Downloads/classicroms/RiscPC_A7000/RO_370/DiscImage</string>

<key>NSNavPanelExpandedSizeForOpenMode</key>

<string>{712, 459}</string>

<key>RPCEmuDataDir</key>

<string>/Users/pmoore/riscpc</string>

<key>RPCHotKeysGrabbed</key>

<false/>

</dict>

</plist>

and here you see the hard drive file:

pmoore@Petes-iMac:~ $ ls -l /Users/pmoore/riscpc/

total 841744

-rw-r--r--@ 1 pmoore  staff        256 21 Mar  2017 cmos.ram

-rw-r--r--  1 pmoore  staff  426360832 27 Apr 20:23 hd4.hdf

drwxr-xr-x@ 3 pmoore  staff         96 19 Mar  2017 hostfs

drwxr-xr-x@ 4 pmoore  staff        128 15 Feb  2016 poduleroms

drwxr-xr-x@ 5 pmoore  staff        160 15 Feb  2016 riscos-progs

drwxr-xr-x@ 4 pmoore  staff        128 19 Mar  2017 roms

-rw-r--r--@ 1 pmoore  staff        243 21 Mar  2017 rpc.cfg

Does the raw device file produced by dd need to be altered in any way for it to work?

On https://www.marutan.net/rpcemu/manual/#hdf, I couldn't see exactly what format the hdf files need to be, so naively just tried using the raw file produced by dd, but suspect that might be the issue?

Thanks for anyone that can help, or redirect me to a better forum to ask the question.

Kind regards,

Pete

P.S. The dd command I used was `sudo dd of=hd4.hdf if=/dev/sdb` which generated the 420MB file which matches the size of the original hard drive. Running e.g. `strings hd4.hdf | grep Acorn` shows that the import seemed to work (there are lots of references to Acorn in the dump).

On 24. Apr 2020, at 18:58, Timothy Coltman <lists@maemagel.com> wrote:

On 24 Apr 2020, at 12:26, Tim Powys-Lybbe <tim@powys.org> wrote:

I have tried to file some comments on GitHub but cannot find where to post them.  Guidance most welcome as I cannot get the program to run with a filesystem.

There is a new release of 0.9.2a that fixes this issue.  My packaging script was not including the "poduleroms" folder, which contains the modules for HostFS and its Filer module.  It was also including the "riscos-progs" folder which isn't required in a binary build.

You can download this from the same place as before:

https://github.com/Septercius/rpcemu-dev/releases

Tim

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] New 0.9.2 Mac binary release

Hi guys!

I installed the new RPCEmu, and managed to dump an image of my RISC PC 600 hard drive using `dd` on linux.

I copied the raw hard disk image to the RPCEmuDataDir as hd4.hdf and have RISC OS 3.60 roms in place.

I followed the instructions on https://www.marutan.net/rpcemu/manual/#hdf but when i run the first command I get the following error:

RISC OS 24MB

Supervisor

*dir aufs::4.$

Disc drive not known (Error number &108AC)

*

My setup looks like this:

pmoore@Petes-iMac:~ $ cat ~/Library/Preferences/org.devrx.RPCEmu.plist

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>NSNavLastRootDirectory</key>

<string>~/Downloads/classicroms/RiscPC_A7000/RO_370/DiscImage</string>

<key>NSNavPanelExpandedSizeForOpenMode</key>

<string>{712, 459}</string>

<key>RPCEmuDataDir</key>

<string>/Users/pmoore/riscpc</string>

<key>RPCHotKeysGrabbed</key>

<false/>

</dict>

</plist>

and here you see the hard drive file:

pmoore@Petes-iMac:~ $ ls -l /Users/pmoore/riscpc/

total 841744

-rw-r--r--@ 1 pmoore  staff        256 21 Mar  2017 cmos.ram

-rw-r--r--  1 pmoore  staff  426360832 27 Apr 20:23 hd4.hdf

drwxr-xr-x@ 3 pmoore  staff         96 19 Mar  2017 hostfs

drwxr-xr-x@ 4 pmoore  staff        128 15 Feb  2016 poduleroms

drwxr-xr-x@ 5 pmoore  staff        160 15 Feb  2016 riscos-progs

drwxr-xr-x@ 4 pmoore  staff        128 19 Mar  2017 roms

-rw-r--r--@ 1 pmoore  staff        243 21 Mar  2017 rpc.cfg

Does the raw device file produced by dd need to be altered in any way for it to work?

On https://www.marutan.net/rpcemu/manual/#hdf, I couldn't see exactly what format the hdf files need to be, so naively just tried using the raw file produced by dd, but suspect that might be the issue?

Thanks for anyone that can help, or redirect me to a better forum to ask the question.

Kind regards,

Pete

P.S. The dd command I used was `sudo dd of=hd4.hdf if=/dev/sdb` which generated the 420MB file which matches the size of the original hard drive. Running e.g. `strings hd4.hdf | grep Acorn` shows that the import seemed to work (there are lots of references to Acorn in the dump).

On 24. Apr 2020, at 18:58, Timothy Coltman <lists@maemagel.com> wrote:

On 24 Apr 2020, at 12:26, Tim Powys-Lybbe <tim@powys.org> wrote:

I have tried to file some comments on GitHub but cannot find where to post them.  Guidance most welcome as I cannot get the program to run with a filesystem.

There is a new release of 0.9.2a that fixes this issue.  My packaging script was not including the "poduleroms" folder, which contains the modules for HostFS and its Filer module.  It was also including the "riscos-progs" folder which isn't required in a binary build.

You can download this from the same place as before:

https://github.com/Septercius/rpcemu-dev/releases

Tim

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] PDFUtils adding .etctension

In message <5866bea540chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

>In article <f858db6558.Terry@tez.freeserve.co.uk>,
> <tk@cestriant.plus.com> wrote:
>> In message <5865cc6cbcchrisg@care4free.net>
>> Chris Gransden <chrisg@care4free.net> wrote:
>
>> > In article <038dbb6558.Terry@tez.freeserve.co.uk>,
>> > <tk@cestriant.plus.com> wrote:
>> >> In message <586558b447chrisg@care4free.net>
>> >> Chris Gransden <chrisg@care4free.net> wrote:
>> >>>> [snip]
>
>> >>> It's to do with the file path conversion in UnixLib. If you use RISC OS
>> >>> paths then the output file paths don't get converted. Shortening to just
>> >>> the file name works as there is no pathg to convert.
>
>> >>> If you change your example command to,
>> >>> pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
>> >>> This should also work.
>
>> >> Thanks for that info Chris.
>> >> Looking at the version of !PDFUtils (0.51) that you produced a few years
>> >> ago with VFP support, it lacked the 'pdftocairo' app. Was there a reason
>> >> for this?
>> >> An updated version (you mentioned 0.65) would also be interesting -
>> >> possibly without VFP support, as that seems to restrict its use to more
>> >> recent machines.
>
>> > At the time of building 0.51 the libcairo library wouldn't build which is
>> > needed by pdftocairo. It builds OK now. I can build a non VFP version of
>> > 0.65 too.
>
>> A more recent build would be nice. I've tested both the VFP version and
>> the earlier non-VFP one, and both worked fine. In limited comparisons
>> there didn't seem to be any speed advantage for the VFP version (is that
>> expected?).
>
>The non VFP version of 0.65 is available at
>https://www.riscosports.co.uk/pdfutils_0.65.0-1.zip.
>
>The VFP version is faster for certain types of PDF files when converting to
>another format.

Thanks have downloaded the new versiona and am using it. Is their plans
to put the new version on here so that one version is in use?
>


--
Kev Wells
http://kevsoft.co.uk/ https://ko-fi.com/kevsoft
carpe cervisium
Bring me my chariot of fire!

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In message <586558b447chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

>
>It's to do with the file path conversion in UnixLib. If you use RISC OS
>paths then the output file paths don't get converted. Shortening to just
>the file name works as there is no pathg to convert.
>
>If you change your example command to,
>
>pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
>
>This should also work.

Thanks I have it working thanks to that, inputing their is no need to
change anything, it is just the outputting that needs the swap. Apart
from with the -svg switch with pdftocairo.


--
Kev Wells
http://kevsoft.co.uk/ https://ko-fi.com/kevsoft
carpe cervisium
The Widow's Uniform is not the soldier-man's disgrace.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In article <f858db6558.Terry@tez.freeserve.co.uk>,
<tk@cestriant.plus.com> wrote:
> In message <5865cc6cbcchrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:

> > In article <038dbb6558.Terry@tez.freeserve.co.uk>,
> > <tk@cestriant.plus.com> wrote:
> >> In message <586558b447chrisg@care4free.net>
> >> Chris Gransden <chrisg@care4free.net> wrote:
> >>>> [snip]

> >>> It's to do with the file path conversion in UnixLib. If you use RISC OS
> >>> paths then the output file paths don't get converted. Shortening to just
> >>> the file name works as there is no pathg to convert.

> >>> If you change your example command to,
> >>> pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
> >>> This should also work.

> >> Thanks for that info Chris.
> >> Looking at the version of !PDFUtils (0.51) that you produced a few years
> >> ago with VFP support, it lacked the 'pdftocairo' app. Was there a reason
> >> for this?
> >> An updated version (you mentioned 0.65) would also be interesting -
> >> possibly without VFP support, as that seems to restrict its use to more
> >> recent machines.

> > At the time of building 0.51 the libcairo library wouldn't build which is
> > needed by pdftocairo. It builds OK now. I can build a non VFP version of
> > 0.65 too.

> A more recent build would be nice. I've tested both the VFP version and
> the earlier non-VFP one, and both worked fine. In limited comparisons
> there didn't seem to be any speed advantage for the VFP version (is that
> expected?).

The non VFP version of 0.65 is available at
https://www.riscosports.co.uk/pdfutils_0.65.0-1.zip.

The VFP version is faster for certain types of PDF files when converting to
another format.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In message <5865cc2eedchrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

> In article <24135f6558.tigger@bc63.orpheusinternet.co.uk>,
> Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
> > In message <586558b447chrisg@care4free.net>
> > Chris Gransden <chrisg@care4free.net> wrote:
>
> > > In article <13d7536558.Kevin@talktalk.net>,
> > > Kevin Wells <kev@kevsoft.co.uk> wrote:
> > >
> > > It's to do with the file path conversion in UnixLib. If you use RISC
> > > OS paths then the output file paths don't get converted. Shortening
> > > to just the file name works as there is no pathg to convert.
> > >
> > > If you change your example command to,
> > >
> > > pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
>
> > Is this also why double-clicking on a PDF in a Sunfish
> > volume reports (from GhostScript)
>
> > Error:/undefined filename injust a
> > (Sunfish::kanae/volume1/Data.$.Dendrogramma/pdf)
>
> > ?
>
> The file name Sunfish give the mount by default confuses the UnixLib
> file conversion. In the SunFish UI naming the mount with just a
> single name fixes it.

I notice that there are a couple of threads about the Sunfish UI
crashing, and it's happening on my Titanium (RO 5.24), although I have
you updated RunImage (dated 8 Jun 2013).

Is there a more up-to-date version?

It's a shame, because Sunfish is excellent, which is why I never
realised I was having issues - it just sat on the iconbar providing my
NAS volumes.

--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [Rpcemu] New 0.9.2 Mac binary release

On 24 Apr 2020, at 12:26, Tim Powys-Lybbe <tim@powys.org> wrote:

I have tried to file some comments on GitHub but cannot find where to post them.  Guidance most welcome as I cannot get the program to run with a filesystem.

There is a new release of 0.9.2a that fixes this issue.  My packaging script was not including the "poduleroms" folder, which contains the modules for HostFS and its Filer module.  It was also including the "riscos-progs" folder which isn't required in a binary build.

You can download this from the same place as before:

https://github.com/Septercius/rpcemu-dev/releases

Tim

Re: [Rpcemu] New 0.9.2 Mac binary release

> On 24 Apr 2020, at 12:26, Tim Powys-Lybbe <tim@powys.org> wrote:
>
>
>
> I have tried to file some comments on GitHub but cannot find where to post them. Guidance most welcome as I cannot get the program to run with a filesystem.
>

This is being caused by the "poduleroms" folder being missing - apologies for that. As a workaround, you can download the source distribution and copy the folder from there; I'll re-release later today.

Tim


_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] New 0.9.2 Mac binary release

I have tried to file some comments on GitHub but cannot find where to post them.  Guidance most welcome as I cannot get the program to run with a filesystem.

Tim

I think you did it right, I see the issue you raised here: https://github.com/Septercius/rpcemu-dev/issues/2

Also my sincerest thanks to Tim (Coltman) for publishing the releases!

Pete

Re: [Rpcemu] New 0.9.2 Mac binary release

Hi,

> On 23 Apr 2020, at 8:03 pm, Timothy Coltman <lists@maemagel.com> wrote:
>
> Hello all
>
> I have built a binary for OS X of 0.9.2 which is now available for download:
>
> https://github.com/Septercius/rpcemu-dev/releases

Many thanks for this, enormously appreciated by the likes of me who have got defeated by trying to compile the code.

> <snip>

> As ever, comments and bug reports relating to Mac support and the binaries are welcome, preferably via the GitHub issue tracker (to avoid cluttering up this list).

I have tried to file some comments on GitHub but cannot find where to post them. Guidance most welcome as I cannot get the program to run with a filesystem.

Tim

--
Tim Powys-Lybbe tim@powys.org
for a miscellany of bygones: http://powys.org/



_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] PDFUtils adding .etctension

In message <5865cc6cbcchrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

> In article <038dbb6558.Terry@tez.freeserve.co.uk>,
> <tk@cestriant.plus.com> wrote:
>> In message <586558b447chrisg@care4free.net>
>> Chris Gransden <chrisg@care4free.net> wrote:
>>>> [snip]

>>> It's to do with the file path conversion in UnixLib. If you use RISC OS
>>> paths then the output file paths don't get converted. Shortening to just
>>> the file name works as there is no pathg to convert.

>>> If you change your example command to,
>>> pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
>>> This should also work.

>> Thanks for that info Chris.
>> Looking at the version of !PDFUtils (0.51) that you produced a few years
>> ago with VFP support, it lacked the 'pdftocairo' app. Was there a reason
>> for this?
>> An updated version (you mentioned 0.65) would also be interesting -
>> possibly without VFP support, as that seems to restrict its use to more
>> recent machines.

> At the time of building 0.51 the libcairo library wouldn't build which is
> needed by pdftocairo. It builds OK now. I can build a non VFP version of
> 0.65 too.

A more recent build would be nice. I've tested both the VFP version and
the earlier non-VFP one, and both worked fine. In limited comparisons
there didn't seem to be any speed advantage for the VFP version (is that
expected?).

--
Regards,
Terry


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[Rpcemu] New 0.9.2 Mac binary release

Hello all

I have built a binary for OS X of 0.9.2 which is now available for download:

https://github.com/Septercius/rpcemu-dev/releases

The binaries are distributed as a DMGs.  There is one for release builds and another for debug builds - most people will want the former.  Each DMG contains both the interpreter and recompiler variants, together with a folder named "Data" that contains the basic files you need to get the emulator up and running.  You'll need to add a RISC OS ROM to this.  Copy this "Data" folder to somewhere of your choice (and rename to suit).  If you've used the emulator before, you can use your existing set-up.

Running the emulator for the first time will prompt you to choose the location of this folder - press the "Select" button and navigate to the folder (make sure to choose the folder itself, not its parent).  Finally, click on the "OK" button and the emulator should start.

This release contains the following:

* V4 of my main Mac patch, including a working keyboard and support for recompiler builds running on High Sierra.

* The patch from David P. that fixes loading of the Ethernet module.

* The patch from Andrew H. that changes the application identifier to be different for interpreter and recompiler builds, enabling you to use both with mouse capture/full screen mode.

* Yesterday's patch that changes the magic key combination for exiting mouse capture mode to Ctrl+Command.

As ever, comments and bug reports relating to Mac support and the binaries are welcome, preferably via the GitHub issue tracker (to avoid cluttering up this list).

Tim

Re: [gccsdk] PDFUtils adding .etctension

In article <038dbb6558.Terry@tez.freeserve.co.uk>,
<tk@cestriant.plus.com> wrote:
> In message <586558b447chrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:
> >> [snip]

> > It's to do with the file path conversion in UnixLib. If you use RISC OS
> > paths then the output file paths don't get converted. Shortening to just
> > the file name works as there is no pathg to convert.

> > If you change your example command to,
> > pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
> > This should also work.

> Thanks for that info Chris.
> Looking at the version of !PDFUtils (0.51) that you produced a few years
> ago with VFP support, it lacked the 'pdftocairo' app. Was there a reason
> for this?
> An updated version (you mentioned 0.65) would also be interesting -
> possibly without VFP support, as that seems to restrict its use to more
> recent machines.

At the time of building 0.51 the libcairo library wouldn't build which is
needed by pdftocairo. It builds OK now. I can build a non VFP version of
0.65 too.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In article <24135f6558.tigger@bc63.orpheusinternet.co.uk>,
Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
> In message <586558b447chrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:

> > In article <13d7536558.Kevin@talktalk.net>,
> > Kevin Wells <kev@kevsoft.co.uk> wrote:
> >
> > It's to do with the file path conversion in UnixLib. If you use RISC
> > OS paths then the output file paths don't get converted. Shortening
> > to just the file name works as there is no pathg to convert.
> >
> > If you change your example command to,
> >
> > pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage

> Is this also why double-clicking on a PDF in a Sunfish
> volume reports (from GhostScript)

> Error:/undefined filename injust a
> (Sunfish::kanae/volume1/Data.$.Dendrogramma/pdf)

> ?

The file name Sunfish give the mount by default confuses the UnixLib file
conversion. In the SunFish UI naming the mount with just a single name
fixes it.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In message <586558b447chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:
>> [snip]

> It's to do with the file path conversion in UnixLib. If you use RISC OS
> paths then the output file paths don't get converted. Shortening to just
> the file name works as there is no pathg to convert.

> If you change your example command to,
> pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage
> This should also work.

Thanks for that info Chris.
Looking at the version of !PDFUtils (0.51) that you produced a few years
ago with VFP support, it lacked the 'pdftocairo' app. Was there a reason
for this?
An updated version (you mentioned 0.65) would also be interesting -
possibly without VFP support, as that seems to restrict its use to more
recent machines.

--
Regards,
Terry


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In message <586558b447chrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

> In article <13d7536558.Kevin@talktalk.net>,
> Kevin Wells <kev@kevsoft.co.uk> wrote:
>
> It's to do with the file path conversion in UnixLib. If you use RISC
> OS paths then the output file paths don't get converted. Shortening
> to just the file name works as there is no pathg to convert.
>
> If you change your example command to,
>
> pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage

Is this also why double-clicking on a PDF in a Sunfish
volume reports (from GhostScript)

Error:/undefined filename in
(Sunfish::kanae/volume1/Data.$.Dendrogramma/pdf)

?

--
Nick Roberts tigger @ orpheusinternet.co.uk

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In article <13d7536558.Kevin@talktalk.net>,
Kevin Wells <kev@kevsoft.co.uk> wrote:
> In message <a18fc36358.Kevin@talktalk.net>
> Kevin Wells <kev@kevsoft.co.uk> wrote:

> >In message <58638e94ccchrisg@care4free.net>
> > Chris Gransden <chrisg@care4free.net> wrote:
> >
> >>In article <66b4915d58.Kevin@talktalk.net>,
> >> Kevin Wells <kev@kevsoft.co.uk> wrote:
> >>> Hi
> >>
> >>> I have noticed a possible bug with PDFUtils, that some of the commands
> >>> add the dos extension complete with a dot.
> >>
> >>> PDFtohtml complains with the following:
> >>
> >>> I/O Error: Couldn't open html file 'full path and file name with .html'
> >>
> >>> I/O Error: Couldn't open html file 'full path and file name with
> >>> _ind.html'
> >>
> >>> PDFtocairo the same as the first mesage but with the extension for the
> >>> image format e.g jpeg tiff png
> >>
> >>> PDFtotext, PDFtoops, PDFunite and PDFseperate all work OK
> >>
> >>> PDFUtils is found at:
> >>
> >>> <http://www.riscos.info/packages/DocumentDetails.html>
> >>
> >>> Thanks.
> >>
> >>Can you send an example of the exact command you are using that fails. The
> >>version on riscos.info is quite old. I can update it to 0.65 which is more
> >>recent and fix the problem at the same time.
> >>
> >>Thanks.
> >>
> >
> >>
> >With pdftohtml the following commands cause problems
> >
> >*pdftohtml RAM::RamDisc0.$.TBOAGsamp/PDF RAM::RamDisc0.$.webpage
> >

> [snip]

> I think I found out was is wrong, if you change the above so that the
> outgoing is called webpage instead of the full pathname, it then saves
> OK to the current Set Directory.

> The same with pdftocairo and pdfimages. I do not know about pdfdetach as
> I have not found a pdf file with embedded files on it.
> >

It's to do with the file path conversion in UnixLib. If you use RISC OS
paths then the output file paths don't get converted. Shortening to just
the file name works as there is no pathg to convert.

If you change your example command to,

pdftohtml /RAM::RamDisc0.$/TBOAGsamp.pdf /RAM::RamDisc0.$/webpage

This should also work.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[Rpcemu] Patch for 0.9.2 on Mac

Hello all

Please find attached a patch for 0.9.2 that changes the magic key combination for exiting mouse capture mode from Ctrl+End to Ctrl+Command. This is aimed at Mac laptop users, whose keyboards do not have a dedicated "End" key. The existing (Ctrl+End) behaviour is preserved for Windows and Linux.

The patch needs to be applied on top of my main V4 patch. Unzip this new patch in the main rpcemu-0.9.2 folder (alongside "netroms", "riscos-progs, "src" et al) and apply via the command line:

patch -p0 -i ./rpcemu-0.9.2-mac-magickeys-v1.patch

Once that's done, configure and build in the usual way. A binary release will follow tomorrow (23/04).

As ever, comments and bug reports are welcome.

Tim

Re: [gccsdk] PDFUtils adding .etctension

In message <a18fc36358.Kevin@talktalk.net>
Kevin Wells <kev@kevsoft.co.uk> wrote:

>In message <58638e94ccchrisg@care4free.net>
> Chris Gransden <chrisg@care4free.net> wrote:
>
>>In article <66b4915d58.Kevin@talktalk.net>,
>> Kevin Wells <kev@kevsoft.co.uk> wrote:
>>> Hi
>>
>>> I have noticed a possible bug with PDFUtils, that some of the commands
>>> add the dos extension complete with a dot.
>>
>>> PDFtohtml complains with the following:
>>
>>> I/O Error: Couldn't open html file 'full path and file name with .html'
>>
>>> I/O Error: Couldn't open html file 'full path and file name with
>>> _ind.html'
>>
>>> PDFtocairo the same as the first mesage but with the extension for the
>>> image format e.g jpeg tiff png
>>
>>> PDFtotext, PDFtoops, PDFunite and PDFseperate all work OK
>>
>>> PDFUtils is found at:
>>
>>> <http://www.riscos.info/packages/DocumentDetails.html>
>>
>>> Thanks.
>>
>>Can you send an example of the exact command you are using that fails. The
>>version on riscos.info is quite old. I can update it to 0.65 which is more
>>recent and fix the problem at the same time.
>>
>>Thanks.
>>
>
>>
>With pdftohtml the following commands cause problems
>
>*pdftohtml RAM::RamDisc0.$.TBOAGsamp/PDF RAM::RamDisc0.$.webpage
>

[snip]

I think I found out was is wrong, if you change the above so that the
outgoing is called webpage instead of the full pathname, it then saves
OK to the current Set Directory.

The same with pdftocairo and pdfimages. I do not know about pdfdetach as
I have not found a pdf file with embedded files on it.
>


--
Kev Wells
http://kevsoft.co.uk/
carpe cervisium
An' hustlin' drunken soldiers when they're goin' large a bit

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [Rpcemu] Another little patch for macOS

This is great, many thanks Andrew and Tim!

> On 20. Apr 2020, at 23:10, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:
>
> The Mac side of the app would need a fair bit of additional code to try and walk the user through the System Preferences changes. Even for apps with large development teams, Catalina seems to have this as a very clunky process; I suppose any kind of programmatic automation of it would negate the benefits, though, as malware could use it to try and bypass the system protections.
>

No worries, the read-me walkthrough sounds perfect, thanks for taking care of that.

> I wrote a PDF read-me for the ROOL macOS version which guides the user through everything, with screenshots.

Yesterday I took my RISC PC 600 apart that I haven't used for > 20 years, and ordered a LogiLink IDE<->USB adapter so I can take an image of the original Conner CFS420A hard drive. I'm hoping this will work and I can emulate my old computer from my Mac. Fingers crossed!
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Another little patch for macOS

On 21 Apr 2020, at 7:54, Timothy Coltman wrote:

> I recently set up a GitHub repository for my RPCEmu builds. It's
> currently private, and doesn't include Andrew's patches, but as I'm on
> furlough for the next three weeks (err, yay?) I will make some time to
> add in Andrew's changes and then make everything available to
> download, including as binaries. I'll post to the list when it's
> ready.

I have complete patched builds for macOS and Windows ready to go with a
5.24 disc image, but we're just waiting on 5.28 being finalised. The
COVID-19 situation has at once caused significant delays, but also
removed various deadline time pressures, so that's helpful in a strange
kind of way.

Tim, if you e-mail me off-list I can share this including the build
script so we can "compare notes", so to speak.

The Mac side of the app would need a fair bit of additional code to try
and walk the user through the System Preferences changes. Even for apps
with large development teams, Catalina seems to have this as a very
clunky process; I suppose any kind of programmatic automation of it
would negate the benefits, though, as malware could use it to try and
bypass the system protections.

I wrote a PDF read-me for the ROOL macOS version which guides the user
through everything, with screenshots.

--
Andrew Hodgkinson
RISC OS Open Limited
http://www.riscosopen.org/

_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [Rpcemu] Another little patch for macOS

On 20 Apr 2020, at 19:45, Peter Moore <petemoore@gmx.net> wrote:

Hi Andrew,

Many thanks for this! If all goes well, is there likely to be a new release for Mac in  http://www.marutan.net/rpcemu/index.php#downloads ? I'd love to give it a try again. :-)

If there isn't an official build, has anyone else already made a build that they have had success with? Is there any way to step the user through the Accessibility setting change ("Allow the apps below to control your computer") if RPCEmu detects the privilege has not been granted at runtime?

Many thanks,

Pete

Hi Pete

Sadly the Mac builds are unofficial at the moment - the various patches that people have submitted have not yet been incorporated into the main source tree.  If you look at older posts on the list there are some releases from David Pitt which may be of interest (early March 2020).

I recently set up a GitHub repository for my RPCEmu builds.  It's currently private, and doesn't include Andrew's patches, but as I'm on furlough for the next three weeks (err, yay?) I will make some time to add in Andrew's changes and then make everything available to download, including as binaries.  I'll post to the list when it's ready.

It does not seem as if you can automatically add something to the accessibility section of System Preferences (though it may be if you have an Apple signed binary, which we do not).  It's fairly straightforward, and you only need it if you use full-screen or mouse capture mode.  

Tim

Re: [Rpcemu] Another little patch for macOS

Hi Andrew,

Many thanks for this! If all goes well, is there likely to be a new release for Mac in  http://www.marutan.net/rpcemu/index.php#downloads ? I'd love to give it a try again. :-)

If there isn't an official build, has anyone else already made a build that they have had success with? Is there any way to step the user through the Accessibility setting change ("Allow the apps below to control your computer") if RPCEmu detects the privilege has not been granted at runtime?

Many thanks,

Pete

On 29. Mar 2020, at 11:18, Andrew Hodgkinson <ahodgkin@riscosopen.org> wrote:

Rounding off the work I've been making doing for macOS X, is the attached patch.

• VERSION is now defined in the QT .pro file, rather than in rpcemu.h
• The Mac application info.plist uses this for the correct application version
• The Mac application bundle identifier is properly composed using qmake variables, leading to a different identifier for the recompiler vs interpreter versions; this allows both of them to be added to Security & Privacy settings as independent entities.

The line numbers in the patch are for a set of sources already patched with Timothy Coltman's V4 Mac patch, but would probably work successfully in unpatched source too using just the diff context. While this small change set is mostly Mac-focused, I do think having the version specified in the project file is the right thing generally and it might be a useful addition to the main source tree.

--   Andrew Hodgkinson  RISC OS Open Limited  http://www.riscosopen.org/

<version-and-bundle-id.patch.zip>_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu

Re: [gccsdk] PDFUtils adding .etctension

In message <58638e94ccchrisg@care4free.net>
Chris Gransden <chrisg@care4free.net> wrote:

>In article <66b4915d58.Kevin@talktalk.net>,
> Kevin Wells <kev@kevsoft.co.uk> wrote:
>> Hi
>
>> I have noticed a possible bug with PDFUtils, that some of the commands
>> add the dos extension complete with a dot.
>
>> PDFtohtml complains with the following:
>
>> I/O Error: Couldn't open html file 'full path and file name with .html'
>
>> I/O Error: Couldn't open html file 'full path and file name with
>> _ind.html'
>
>> PDFtocairo the same as the first mesage but with the extension for the
>> image format e.g jpeg tiff png
>
>> PDFtotext, PDFtoops, PDFunite and PDFseperate all work OK
>
>> PDFUtils is found at:
>
>> <http://www.riscos.info/packages/DocumentDetails.html>
>
>> Thanks.
>
>Can you send an example of the exact command you are using that fails. The
>version on riscos.info is quite old. I can update it to 0.65 which is more
>recent and fix the problem at the same time.
>
>Thanks.
>

>
With pdftohtml the following commands cause problems

*pdftohtml RAM::RamDisc0.$.TBOAGsamp/PDF RAM::RamDisc0.$.webpage

Which gives the following error:

I/O Error: Couldn't open html file 'RAM::RamDisc0.$.webpage.html'
I/O Error: Couldn't open html file 'RAM::RamDisc0.$.webpage_ind.html'

Fatal signal received: Segmentation fault

Stack backtrace:

Running thread 0x613758
( 61cf38) pc: 4c94cc lr: 4c9a54 sp: 61cf3c __write_backtrace()
( 61cfa0) pc: 4c95f0 lr: 47ca88 sp: 61cfa4 __unixlib_raise_signal()
( 61cfb0) pc: 47c98c lr: 12a5c sp: 61bf00 __h_cback()

Register dump at 0061cfb4:

a1: 4e3b64 a2: 1 a3: 10 a4: 736f6847
v1: 736f6847 v2: 10 v3: 63dcb0 v4: 4e3b64
v5: 63dcb0 v6: 613fc4 sl: 61b208 fp: 61bf28
ip: 0 sp: 61bf00 lr: 12a5c pc: 47dce0
cpsr: 60000110

0047dccc : .p á : e1a07000 : MOV R7,R0
0047dcd0 : ..å : e58d1000 : STR R1,[R13,#0]
0047dcd4 : .P á : e1a05002 : MOV R5,R2
0047dcd8 : .@ á : e1a04003 : MOV R4,R3
0047dcdc : .... : 1a00000c : BNE &0047DD14
0047dce0 : .0"å : e5943000 : LDR R3,[R4,#0]
0047dce4 : þ.Sã : e35304fe : CMP R3,#&FE000000
0047dce8 : .... : 0a00000d : BEQ &0047DD24
0047dcec : t2Ÿå : e59f3274 : LDR R3,&0047DF68

( 61bf28) pc: 47dcb4 lr: 12a5c sp: 61bf2c fwrite()
( 61bf48) pc: 12918 lr: 8d14 sp: 61bf4c HtmlOutputDev::~HtmlOutputDev()()
( 61bfec) pc: 8564 lr: 48accc sp: 61bff0 main()


Using the noframes option

*pdftohtml -noframes RAM::RamDisc0.$.TBOAGsamp/PDF RAM::RamDisc0.$.webpage

Gives the following error

I/O Error: Couldn't open html file 'RAM::RamDisc0.$.webpage.html'

Creating a directory called webpage gives the following error

I/O Error: Couldn't open image file '%s'
Page-1
Page-2
Page-3
I/O Error: Couldn't open image file '%s'
Page-4
Page-5
Page-6

etc, but does create a file called html

With pdftocairo the -svg and -ps options seem to work OK but with -png
-jpeg and -tiff does not I will use the -png option but the same error
with the rest

*pdftocairo -png RAM::RamDisc0.$.TBOAGsamp/PDF RAM::RamDisc0.$.image

Gives the following error:

Error opening output file RAM::RamDisc0.$.image-01.png

If I then create a directory called image-01 then a file called png is
saved inside that directory but it then gives the same error but with 02
instead of 01 etc.


Many thanks.

--
Kev Wells
http://kevsoft.co.uk/
carpe cervisium
And did the countenance divine

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] GCC 8 sanitizer

In article <ef614700-c10b-c683-7641-d14f888c167a@sky.com>,
Lee Noar <lee.noar@sky.com> wrote:
> On 10/04/2020 19:19, Chris Gransden wrote:
> > I noticed GCC 8 accepts the -fsanitize options but fails at the link stage.
> > Is this something that could be added or does it need specific OS support
> > for it to work.

> I've had a look at the source for this, and it appears to require
> intimate knowledge of glibc. I think it would need a lot of work
> before we could even determine whether it was feasible.

No problem. Time better spent elsewhere.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] PDFUtils adding .etctension

In article <66b4915d58.Kevin@talktalk.net>,
Kevin Wells <kev@kevsoft.co.uk> wrote:
> Hi

> I have noticed a possible bug with PDFUtils, that some of the commands
> add the dos extension complete with a dot.

> PDFtohtml complains with the following:

> I/O Error: Couldn't open html file 'full path and file name with .html'

> I/O Error: Couldn't open html file 'full path and file name with
> _ind.html'

> PDFtocairo the same as the first mesage but with the extension for the
> image format e.g jpeg tiff png

> PDFtotext, PDFtoops, PDFunite and PDFseperate all work OK

> PDFUtils is found at:

> <http://www.riscos.info/packages/DocumentDetails.html>

> Thanks.

Can you send an example of the exact command you are using that fails. The
version on riscos.info is quite old. I can update it to 0.65 which is more
recent and fix the problem at the same time.

Thanks.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: libcss selection question

Hi Paul,

When you have a computed style, you can't tell anything about the specificity of the individual properties.

The way to handle this is to provide the `node_presentational_hint` callback [1].  When it is called, you look at the node's attributes and set any appropriate styles as `css_hint`s [2].

1. http://source.netsurf-browser.org/libcss.git/tree/include/libcss/select.h#n120

2. http://source.netsurf-browser.org/libcss.git/tree/include/libcss/hint.h#n34

Hope this helps,

Michael

On Thu, 16 Apr 2020 at 11:40, Paul <paul.gruzdev@gmail.com> wrote:

Hi all!

How can a user of libcss distinguish between these two situations: a)
property was defined using a default value in CSS and b) property was
undefined in CSS for the node. Those are different because in a latter
case the value of that property should be taken from a node attribute
(in my case of svg styling). As far as I can tell, for a root node, the
property is always initialised using the default value, so when
composing a style I can't distinguish between a and b.

Thanks,

Paul

libcss selection question

Hi all!

How can a user of libcss distinguish between these two situations: a)
property was defined using a default value in CSS and b) property was
undefined in CSS for the node. Those are different because in a latter
case the value of that property should be taken from a node attribute
(in my case of svg styling). As far as I can tell, for a root node, the
property is always initialised using the default value, so when
composing a style I can't distinguish between a and b.

Thanks,

Paul

Re: HTML5 element support

Michael Drake <michael.drake@codethink.co.uk> wrote on 14 Apr 2020:

> It looks like a problem with our Hubbub library. (The HTML5 spec
> has moved on a long way since it was written.)

Thanks for your help

>> If Netsurf is supposed to support HTML5 elements perhaps I should log this
>> as a bug on the tracker.

> Please do!

I have reported it. Wasn't sure what to put for 'severity', minor seems a
bit too low but 'major' (which I plumped for) is probably too high, could
have done with a 'moderate' option!


--
Ewen Pring, St. Albans, Herts
using RISC OS 5
https://timebus.co.uk/riscos/

Re: HTML5 element support

On 14/04/2020 17:18, Ewen Pring wrote:

> At least some of my problem can be seen at these 2 simplified test pages:
>
> https://timebus.co.uk/riscos/webtest/using-html4.htm
> https://timebus.co.uk/riscos/webtest/using-html5.htm

Those are great, thanks!

It looks like a problem with our Hubbub library. (The HTML5 spec
has moved on a long way since it was written.)

> If Netsurf is supposed to support HTML5 elements perhaps I should log this
> as a bug on the tracker.

Please do!

Cheers,

--
Michael Drake https://www.codethink.co.uk/