Jump to content


mjashby

Member Since 19 Sep 2014
Offline Last Active Sep 11 2019 12:50 AM
-----

Posts I've Made

In Topic: Not optimised for Mac

21 August 2019 - 08:17 AM

Crossover can't provide an updated RootsMagic 7 package because there isn't yet a working solution for Apple's decision to prevent any software application that makes 32-bit system calls from running on 'Catalina Beta', or on the release version of Catalina which is still not due to land until late-September at the earliest.

 

The better way to keep a check on 'progress' would be to monitor relevant discussion threads on:

 

 - the WineHQ Mac Forum - https://forum.winehq...ewforum.php?f=9  e.g. https://forum.winehq.org/viewtopic.php?f=9&t=32590 

 - the Crossover Mac Forum: https://www.codeweav.../general/?;t=27  e.g. https://www.codeweavers.com/support/forums/general/?t=27;msg=212891 

 

There simply is nothing the RootsMagic developers, or anyone else can do about RootMagic 7 until/unless an effective programming solution is found by Wine developers in partnership with Crossover and others, which simplistically means "A way of programatically convincing MacOS (Catalina and later) that it is running 64-bit processes when it isn't!".  And before anyone asks the obvious question. No, simply installing 32-bit Windows software in a 64-bit Wine Wrapper won't work because the resulting app still contains the essential 32-bit system calls, just as real Windows systems do, which is what the next MacOS version is/will be designed to recognise and prevent from running.  In contrast Microsoft has come out strongly against dropping the ability to run 32-bit software on 64-bit Windows systems; and major Linux developers, such as Ubuntu, have stated that, although they are unlikely to continue to release 32-bit builds of their future OS releases, they will continue to maintain their OS's ability to run 32-bit software.

 

Sorry to say this, but anyone running 'Catalina Beta' on a production system, i.e. a system which is required to work reliably and preserve user data securely, only has themselves to blame if any of their software no longer works, or if any data becomes corrupted, as Apple clearly advises beta users NOT to deploy Beta Versions on such systems.  I would extend that to anyone intending to install the release version of Catalina immediately on release really needs to think seriously about the potential impact if something goes belly up.  Thinking back, Mojave certainly wasn't an easy ride for many users and there have been continuing problems with far from perfect updates since its initial release.


In Topic: Generated reports not scaling properly

22 May 2019 - 01:31 AM

The Knowledge Base article Renee pointed to gives a good summary of the behaviour I referred to.  

 

Think of it this way: If you have a 'modern' laptop with a HiDPI (High Definition Dots Per Inch) Screen set to its maximum display capability (which most computer users have no genuine need for) and an 'old' printer (or any software) which was produced before such displays were widely available, then that is somewhat equivalent to expecting a 1990s TV to be able to accurately display a Ultra High Definition DVD Film.  It's simply not going to happen without a conversion process.

 

Mervyn 


In Topic: Generated reports not scaling properly

20 May 2019 - 02:05 AM

First thing to check should probably be the Printer/Printer Driver software in use, including any PDF Printer Drivers that you may have installed.  Has it/Have they been updated since you moved to an HDiPI display system (i.e. is all of your software HDiPI aware - fully compatible with HDiPI screen displays)?

 

I may be wrong but this is a relatively common issue, as many users keep their peripheral hardware (and its original software/drivers) for much longer than their PCs/Laptops.


In Topic: Date Formatting

15 May 2019 - 02:37 AM

How does that format cope with and provide clarity with 'dual dating', e.g. 06 Mar 1655/56?

How does it clearly identify whether a date prior to 1752 came from the Julian Calendar, or has been 'transposed' to a Gregorian date; which would, if calculated correctly, be completely different, to what was recorded in the original document?

How does it handle 'Quaker Dates' prior to 1752, where Month 1 (i) was March & 10 ('x') was December?

 

No wholly numeric system can provide complete clarity and I don't see how ISO 8601 could possibly be successfully applied to the recording of all historic dates, or to any Calendar that does not/did not conform to a general European/US perspective/modern expectation. This difficulty applies particularly where calendar inconsistencies existed (and continue to exist) and/or where there were clear historic differences in calendar usage, e.g. the Gregorian Calendar was not 'universally' implemented across Europe on a single date, That change wasn't even implemented across the 'Great Britain' in the same year, as Scotland accepted the Pope's decree on the implementation date for the Gregorian Calendar, but England & Wales (and the 'Colonies') didn't.


In Topic: How to cite evidence for photos and audio?

29 April 2019 - 05:51 AM

1. Whatever can be found that determines/evidences the provenance of the article/image/document etc. - https://en.wikipedia...wiki/Provenance

 

2. The most logical placement, in my opinion, would be in the Media Record (Properties - Description), which also allows you to record any outstanding concerns about the provenance of the Media, but others may suggest alternative options.