Since I built a .odt file reader for Bookapy's EPUB builder, I ported the code to SOL's submission system.
So as of today, those of you writing in LibreOffice can submit your .odt files directly.
Formatting support is limited to Header styles, bold, italic and superscript.
No embedded images supported.
*My submissions as .txt are still suffering from extraneous characters added by SOL. Would it improve if I submitted as .adt?
Check the .txt file in a basic text editor (Notepad on Windows).
I submit as .html saved from LO ODT. I ran into an issue with a few submissions of an extraneous newline in the middle of a sentence. It didn't show in the ODT master file in LO, and it didn't show in the .html file if I opened the .html in LO.
However, if I viewed the .html file in my browser, the extra newline was there.
Usually, it depends on how each writing tool handles the ubiquitous 'publishing' marks, like smart-quotes and em-dashes and epilepsies, as SOL expects them to be formatted according to the SOL standards, not anyone else's. So since I mainly focus on self-publishing my books, I concentrate on html codes, which are pretty universal, yet those same 'publishing marks' are still problematic.
Yet, in you play in a given 'yard', you play by the house rules. So once again, get over it, as you can just as easily move to someone else's yard instead. (No offense, yet it's the old "My House, My Rules" we've always heard.
Usually, it depends on how each writing tool handles the ubiquitous 'publishing' marks, like smart-quotes and em-dashes and epilepsies, as SOL expects them to be formatted according to the SOL standards, not anyone else's.
Okay, but a new line (what I had a problem with) isn't a 'publishing mark'.
I'd said 'usually'. However, recall that different systems use different definitions of 'new lines'. Some use simple carriage-returns while others use a combination carriage-return/linefeed. Thus, if you determine which your system is generating, then simply substituting one for the other resolves ANY potential conflict.
In my case, anytime I want to center one line directly under the other (keeping them lined up) I'll just add a simple 'lf' character, so it's relatively separating them, but you need to know what your Operating Systems default 'next line" consists of. Again, as simple global search and replace should resolve any problems.
Both I and Lazeez use Mac computers, yet those using either PCs or Linux system frequently encounter 'issues' such as you're describing. The extra global search and replace can become tedious after a while, yet it usually resolves ALL the problems entirely.
I'd said 'usually'. However, recall that different systems use different definitions of 'new lines'. Some use simple carriage-returns while others use a combination carriage-return/linefeed. Thus, if you determine which your system is generating, then simply substituting one for the other resolves ANY potential conflict.
That should only be a problem when going back and forth between different systems, which I wasn't doing. As I said, the extra new-line was in my file on my end, but I could only see it viewing the HTML file from a browse.
I could only see it viewing the HTML file from a browser.
If you do not see it in libreoffice but see it in the browser, only 2 explanations are possible:
1 Libroffice used a pre tag for the conversion AND
* The browser conform to UAX14-C1 or UAX14-C2 (libroffice doesn't.)
* You have a special invisible character present on that line or at the break in the libreoffice document.
2 Libreoffice used a br tag for the conversion AND
* Libreoffice html conversion choose to conform to UAX14-C1 or UAX14-C2 (it probably shouldn't!)
* You have a special invisible character present on that line or at the break in the libreoffice document.
Check the html source to see if you are in case 1 or 2
For the especial character, the usual ascii suspect are vertical tab vt, carriage return cr, form feed ff, line feed lf.
But unicode added a astonishing plethora of other offenders see:
https://www.unicode.org/reports/tr14/tr14-51.html
The browser, mostly ignore them as do libreoffice but the conversion process from lo to html probably obeyed one and borked.
Cleaning the libreoffice document of unwanted unicode, should solve it...
You have a special invisible character present on that line or at the break in the libreoffice document.
There was no break at all in the libreoffice document where the stray newline was. One of the cases was literally in the middle of a word.
The culprit is a non visible character, it has zero width. You would not see anything in lo. Possibly if you move the insertion point using the arrows, you may see a spot where an arrow right doesn't appears to move the insertion point. But that is not the case for all problematic unicode char.
Give it a try. It should fix whatever issue you may be having with .txt files.
What extraneous characters?
Example sent me by a reader:
> > I knew it as ëspud picking week' in England
> >
> > they had the ëtattie-picking holiday'
> >
> > or your name, as ëJohn Meadows party',
> >
> > "UmmÖ I have only spoken with them
> >
> > "Oh. Jane Proudfoot and Deborah ñ Debbie ñ Brown."
> >
> > "I meanÖ what they said about marriage?
> >
> > who brought you here ñ operate a telecomms service
> >
> > chapter-21-reginald-on-rehome
> >
> > going to open a pharmacy ñ perhaps you mentioned
> >
> > "You won ët stay single for long, girls.
> >
> > you taking the ëwives' aspect to the bedroom.
> >
> > "But, butÖ we have only just met,
What encoding are you using when you save the .txt file? It looks as if the punctuation is being converted to alternate characters. Try exporting in UTF-8 encoding.
UmmÖ I have only spoken with them
Any submission format, other than .txt avoids this issue. .docx, .odt, .html and even pasting your text into the form avoids this.
Usually, those are Mac encoded characters that are treated as windows ones.
A couple of months ago I made a change in the processing flow that detects these characters. Is that text from recently, or from text posted long ago?
One puzzling thing though, from every test I've ever conducted with LibreOffice, if you do a 'Save As...' and select .txt, the resulting file is usually encoded in UTF-8 with BOM, and such a file won't have miscoding and won't be mis-processed by our software.
Usually, those are Mac encoded characters that are treated as windows ones.
I've also seen this if the wrong code page is selected in Windows, but I haven't used Windows for anything important in nearly a decade, so I don't know if that's still a concern.
If he's using a Mac, he should switch to BBEdit if he wants to create text files. The free version will do everything he needs and is how I've written 13,000,000 words in the past eight years. :-)
if you do a 'Save As...' and select .txt, the resulting file is usually encoded in UTF-8 with BOM
LibreOffice save as with file type "Text" will use the system encoding, it varies with the system!
Mac and most Linux by default have a default UTF8 encoding (my recollection was without BOM.)
On windows it default to the system ANSI codepage which varies with the system language. In W10 there is a checkbox labeled "Beta" to change that to UTF-8 it is hidden in the Control Panel, Regional Settings Administrative tab: "language for non unicode programs"
So unless you change the system code page, you can't rely on Save as with File type "Text (*.txt)"
Instead, you need to use File type: "Text - Choose Encoding (*.txt)" and check "Edit Filter" then "Save", on the next "ASCII Filter" dialog select UTF-8 and check the BOM option then ok.
Unfortunately it's my experience that upon LO restart, the Filter Settings are lost.
Perhaps I am too picky but having had some difficulty in odt to ePub book conversion, I've switched to using Calibre to do the conversion. The one issues I have with several conversion utilities is that they create duplicate styles. So my solution is to this is to edit it after creating the ePub from an odt file. It takes a bit of time, but I think leads to a nicer product. It also takes some effort to learn some of the ePub formatting code, but it is not hard. There are many resources on the internet to assist in understanding the ePub formatting code. Also, Ernest Bywater wrote a nice book describing the steps needed to create a good compact ePub. So you might want to take a gander at it. BTW after I've done all the editing, I open the ePub using several readers to make sure it displays as intended.
I haven't checked to see if those style guides are still on his webpage, but if they aren't I have copies.
I am informed by a reader that my Nowhere Man, Book One, previously perfectly fine, now has errors on almost every page. I presume this is down to SOL software glitches, so can I pass on this information so that you can look into it in case it affects other author's work?
I presume this is down to SOL software glitches, so can I pass on this information so that you can look into it in case it affects other author's work?
No, not our software glitches. .odt is now handled by LibreOffice itself on the server.
However, it happened a couple of weeks ago for a story that I know well, the author submitted an update and it was full of issues. I double checked everything and it turned out that the author that submitted hadn't accepted and finalized all the changes done by the editor and any deleted/replaced text was still in there.
So, you must finalize any changes, either accepting all or accepting or rejecting, but all the tracked changes need to be finalized otherwise the text on the site will be messed up. There is no way for me to do it on the server as LibreOffice does not provide a command-line option to do so.
There is no way for me to do it on the server as LibreOffice does not provide a command-line option to do so.
Indeed, but you could load a macro in headless mode and pass the file name as macro argument. The macro could then do some cleanup such as accept all changes (or warn of the situation)
Indeed, but you could load a macro in headless mode
I saw that in the documentation after my initial response.
I thought about doing it, but then I decided not to since maybe the author doesn't want to accept all of them.
Hmm. Methinks it could be time for a feature request: https://bugs.documentfoundation.org/
Any feature can be useful to many, but as I replied above, I won't implement it.
The author/poster should be more diligent with these issues.
Perhaps it would best to reject updates if there are changes that have not been accepted? (Assuming it's easy to detect that is the case?)
Perhaps it would best to reject updates if there are changes that have not been accepted? (Assuming it's easy to detect that is the case?)
Not detectable. So no, it's still up to the author to finalize things.