This is not a new issue … but needs be reported here again. We have lots of notes in 2 projects which have several alines of information and explanation. We may have over 500 of those in each project. It is not user-friendly to let the reader go through this without any ordering in parts.
We are not working in Paratext but thankful our system works fine with SAB.
I plead for a solution for this situation …
USFM does specify a \fp marker that is a footnote paragraph. The underlying standard can handle what you want.
If you are importing DOCX it is converted to USFM. You could export and edit the USFM to include the \fp marker.
If you can specify how your DOCX is marked up for paragraphs in Word footnotes you could ask for a feature request for \fp to be added to the DOCX conversion to USFM.
Indeed there is a \fp marker in the USFM manual but even with the addition of a hard return before it, it does not work in SAB 4.7.1. I tried several times. (VERY HARD )
Below how it looks like in in note:
\fp Als je jacht maakt op pythons voor een feestmaal, betekent het dat je ze levend moet vangen. Er zijn hier in Nieuw-Guinea geen koelkasten, geen manieren om voedsel goed te houden, en als een slang eenmaal dood is, bederft het vlees snel. De enige manier om het vlees vers te houden, is de slang in leven te houden.
\fp Jagen op pythons is een soort match voor de Folopa’s. Het is een wedstrijd, en vooral zo opwindend omdat de inzet hoog is. Ze praten graag over vroegere jachtpartijen en vertellen uitvoerig allerlei oude verhalen. Vooral over de keren dat het maar net goed ging. De python breekt je botten … zijn tanden zijn scherp, het lijken wel honderden naalden die allemaal naar achteren zijn gericht.
\fp etc.
Am I making a mistake in the notation or is here something wrong in SAB?
In the DOCX or DOC which I export to HTML we have no footnotes at the moment and we are glad with the display of these docs in the APP.
This issue was added as bug during SAB version 4.7 on Nov. 18.
It has not been dealt with in version 4.7.1, the version we use now on MacOS Mojave
Will it be dealt with in version 5.0? We really need to have the \fp marker working in the FOOTNOTE and at the moment it does not work!
By the way we cannot get the APPs working any more in the Simulator …
@mcquayi, I made a pre-release build of 5.0 available to @joop. He said that the \fp worked but there is still an issue for him with the Simulator. I will attempt to take a look at that before we release 5.0.
This procedure works, though starting the Simulator (ad. 3) took 6-7 minutes even after a Restart of my Mac.
The resizing of text in the Simulator works fine in the bible text, but does not work at all in the footnote text!
Also I think article 1 should read like this:
click on Run iOS App in Simulator button to open the dialog and just do Build . When finished close the Run iOS Simulator dialog box.
Glad it works, but speed is really a point of concern. I have an iMac 27" construction date late 2013 , 3.2 Ghz,IntelCore i5 with Mac OS Mojave 10.14.2
@joop, the Simulator comes with Xcode. We have no control over its performance. The Run iOS App in Simulator dialog is just there to make it slightly easier to interact with the Simulator.
If the Simulator is slow to start, then it is due to your computer. It could be the amount of free memory or speed of your hard drive (SSD is much faster than spinning disk). How much memory do you have? What type of disk do you have (HDD, Fusion Drive or SSD)?
I started the Simulator on a few Macs (all with High Sierra) that I have access to see the difference in start times:
My computer: 2017 iMac 3.4GHz Core i5 with SSD and plenty of memory = 25 seconds
Our Build Machine: 2014 Mac Mini 2.6GHz Core i5 with Fusion Drive and 8GB of memory = 35 seconds
Another Mac: 2014 Mac Mini 1.4GHz Core i5 with HDD and 4GB of memory = 5 1/2 minutes
FYI, every time you do Build iOS App it also builds the Simulator version of the app, but it requires that you have the iOS signing configuration correct. Doing the simulator build from the Run iOS App in Simulator is quicker and doesn’t require the iOS signing configuration.
I have 8GB, should be ok - see your test on the minimac from 2014
There maybe a problem with the signing configuration for Mac, (I am still seeking a solution and I will give it an other try in the course of this month),
On the other hand in the past, it seems not to cause any problem.
Before Mojave and before SAB 4.7 or 4.7.1, it worked well enough and it was convenient to check my work this way.
I suggest somebody tries on Mojave … thank your for your explanation and I fully understand that you cannot control factors which are related to Xcode etc.