Forum: Author Hangout

Shouldn't be, because I paste from Word into a text editor which strips all formatting, do a final check, then manually paste the chapter upload into the submission engine.

It looks like the steps you think you did were: Copy from Word, Paste into text editor, Copy from text editor, Paste in submission wizard.

You might have accidentally hit Paste when you thought you were doing the second Copy. You could easily not notice that and the Paste into the submission wizard would then have been another copy of the Word document.

the text displayed looks like MS WORD's header material.

No, word docx format is zip, it start with "PK"
Note that LibreOffice OASIS Open Document format specification also specify the use of zip.

This one start with "BZh" and that is the header for Bzip2 compression.
https://en.wikipedia.org/wiki/Bzip2

So that can't be it...

Thanks, Ernest. I think I will go down the filtered HTML route for future stories.

Yes; https://www.w3schools.com/html/html_entities.asp

Yes

Thanks. I bookmarked that link and will test it soon with a revised version of an old story. :-)

Just checking ... Can I write a doc file in OpenOffice including things like: &nbsp. When the story is ready to go, I 'Save As' my file, selecting type of html. Presumably I should then check both version side-by-side. If the appearance of the html version is as I want, then it's ready. Right?

To make the final check easier, can I put the html entities, but only those, in bold font in the doc file?

Thanks.
I need to remember that html commands must be ended with a semi-colon.
I would only use non-breaking spaces before ellipses and dashes and ordinary spaces after, but that's moot as the submission wizard does not allow non-breaking spaces through.
I'm not aware of any differences between OO and Word I need to be bothered about.

Got it. Thanks.

Thanks, EB.

I just got back from sending off an enquiry to Lazeez.

I scanned the links you provided. It's nice to be aware of what exists, but for my purposes, if a non-breaking space is not available then what I currently do ain't broke.

I sued to have to change

That must have been complicated, not to mention expensive with you in Australia and Lazeez & SOL in Canada. :)

As far as I know, the addition of the em-dash was the last html code added to SOL

They definitely work now.
I posted a revised version of a chapter yesterday. I had single characters in my doc file for ellipses, en-dashes, and em-dashes. They all survived both saving my doc files with txt format, and the submission wizard allowed them through to the posted version.

... but the curly apostrophes are now allowed through...

Unfortunately when you download the stories as text files, they have very strange character combinations in their place.

download the stories as text files

Every time I've tried to do that, I've received a document that was nothing except text; no spaces, no punctuation, just one solid mass of text crammed into one very large "word".

This doesn't happen to other people?

Actually, that's good to know.

I'd really rather it was just something weird happening with my interactions with the site, than it being the way it works for everyone.

Maybe I'll try it again, and see if I can figure out what's happening.

*****

Well glory be, it worked this time!

Change the suffix of the file to ".rtf" and the story snaps into place.

Every time I've tried to do that, I've received a document that was nothing except text; no spaces, no punctuation, just one solid mass of text crammed into one very large "word".

If I open the txt file with Notepad, it displays a a single paragraph. If I open it with WordPad, the paragraphs display properly, but the curly apostrophes show as ’ and quotes display as “ and â€

If I open it with WordPad, the paragraphs display properly, but the curly apostrophes show as ’ and quotes display as “ and â€

Only some files do that. However, it's only a couple minutes to fix with a search and replace if it's too irritating to live with.

That may be due to the system where by you're getting it as a text file or it may be on older file with the older code.

I don't know where the problem lies. I am on a Win8.1 system but use LO as my primary word processor. Since you referred to your Rough Diamond story, I used it for my testing purposes. I downloaded the story as text file using the TXT button, I got the file Rough_Diamond@Ernest_Bywater.txt which opens by default with Notepad. In Notepad, the Table of Contents displays properly but the story becomes a single paragraph. Opening the same file in WordPad gives me properly formatted paragraphs, but I get the strange characters I noted before. Opening in LO I still get the strange characters, but I also see (with 'Formatting Marks' turned on) that the paragraphs are separated by line breaks (Shift+Enter) instead of paragraph break. I also get paragraph breaks in unusual places, usually in the middle of a sentence.

As sandpiper suggested, it's a fairly simple matter of me doing a find & replace to make corrections, but should I have to?

This would seem to be an issue with Notepad and not SoL or the file.

Although not an SOL problem, I expect Lazeez has been asked about such things before and could explain what is happening.

I'm using Opera as browser and tried to save from ASSM as text. When opening in Notepad the textfile was without linebreaks and in most cases the two words were glued together. I assumed this is a problem of Opera and as a work-around selected the whole text in Opera to copy+paste it into Notepad. This worked fine.

Now reading this thread I guess it's first the preselection of the character coding used by notepad when opening files – not UTF-8 – and second the way the different operating systems code and interprete NewLine. (Which codes are created by the OS and passed to the wordprocessor when the user presses the Return or Enter keys of their keyboard?)

In the early days with teletypes used as cheap printers 'Carriage Return' and 'Line Feed' were necessary and in this sequence: CRLF. (print head to the left and paper one line up). If you reversed the codes (LFCR) the first character was printed somewhere in the left half of the line while the print head was still moving.

Back when I had to code protocol files created by my program, which were copied and read on Unix and Windows and Apple machines I learned that using only one of the codes (CR alone, LF alone) did work as NewLine but not with all OS's.
One of the 3 OS did LFCR without problems while DOS/Windows interpreted the 'LF' as a 'Line Feed' without change of the printing position (same column) and the following 'CR' as a 'Carriage Return' with an implied 'Line Feed', thus moving the paper two lines upwards.

HM.

Notepad

You should try using notepad++ https://notepad-plus-plus.org/

The characters you're having trouble with are the Unicode characters U+ 2019, U+ 201C, and U+ 201D (spaces to stop running as code) being misread by Notepad and saved as the wrong character. I'm not sure if these are UTF-8, UTF-16, or UTF-32 or why they aren't showing right in Notepad.

That would make sense IF the strange characters were showing up in Notepad. The only issue in Notepad is that the story becomes one long paragraph. It is only when I open the file in other word processors (WordPad, OpenOffice, LibreOffice) that the strange characters appear.

When I cut/paste from SOL to Notepad or Wordpad I end up with completely unformatted text.

When I cut/paste from SOL to OpenOffice or LibreOffice, the formatting is correct but I end up with non-breaking space on either side of the formatting EXCEPT when the formatted word/sentence ends in punctuation. For example:

"It was their choice." There would be a nbsp on either end of their

"It was their choice." There would be a nbsp at the beginning of choice but not at the end.

because I sued to ...

Who's splitting hares now? :-)

because I sued to ...

Who's splitting hares now? :-)

I am quite sure he meant the definition

. to make suppliant requests of

I am quite sure he meant the definition "to make suppliant requests of"

I'm not sure what to make of that one.

I suspect you didn't realise my post was a continuation of a running joke EB have been having about wrong words making it through into posts here.

Maybe you intended a joke with your use of highfalutin' language. If so, speakers of BrE may have problems getting it. My OxD does not include the word 'suppliant'; it only has 'supplicant'. Just to be sure, I tested 'suppliant' in dictionary.com. It listed it as having the meaning 'supplicating'.

Sigh! It looks like another example of Americans mis-suing a word so often it becomes accepted as a real word. (There may be hope for you yet, EB :-)

Until that point, I thought you were trying to be very clever by adjusting the spelling of "supply-ant". The meaning of that didn't quite work.

Maybe you intended a joke with your use of highfalutin' language.

Nah. I knew what I intended to say but couldn't put it into words so I just did a copy/paste from one of the online dictionaries. You can blame the 'highfalutin' language' on them.

Who's splitting hares now? :-)

The barber? :)

The barber? :)

No. The butcher for hares. :-)

I don't know why those characters are being messed up,

I 'think' I found the issue to be with LibreOffice. For some reason LO does not allow you to specify the file encoding UNLESS you go:

File> Open> File Type> Text - Choose Encoding

ROYAL P.I.T.A.!

In any case I just recorded a quick macro to go through and fix a couple of things that I don't like doing with Find & Replace. Now if I could just automate it.

But I'm using Zorin Linux and not MS Windows, and I don't know if that makes a difference or not.

I bet it makes a difference. Windows and Unix/Linux use by default different character sets.
AFAIK, there is still no generally accepted standard how and where in the file to store which character set was used to create a text file.

OTOH, any HTML file contains something like this: encoding='utf-8'

With text files you have to guess.
In the 'open' dialog for Notepad you can select the encoding you believe was used when creating the file.
On my Windows system it's ANSI, Unicode, Unicode Big Endian, UTF-8. Default is ANSI.
If you get strange characters displayed, reopen the file with another selection.

HTH,

HM.

BTW, last time I had to deal professionally with different encodings was about 25 years ago when we tried to read data from a Siemens PLC with a Big Endian processor. All data we got was in the wrong order. It was a PITA to create a conversions subroutine to convert 4 byte floating point values into usable data.

File> Open> File Type> Text - Choose Encoding

ROYAL P.I.T.A.!

As Lazeez said earlier, text encoding matters. UTF-8 has been accepted as the web standard.

Also, the long-standing headache of line endings has been resolved by accepting the Linux convention of "LF" as a line ending, normally found only at the end of a paragraph. The Windows convention requiring a "CR LF" at the end of each window wrap point (ie, hard returns) is obsolete and non-standard, but some Windows text editors still demand it.

Problem solved if one uses a modern text editor, or a word processor that exports text that meets the UTF-8 encoding, LF line ending standards.

Mac users have fought this Windows text convention nightmare for years.

The Windows convention requiring a "CR LF" at the end of each window wrap point (ie, hard returns) is obsolete and non-standard, but some Windows text editors still demand it.

M$ in it's wisdom insisted on backward compatibility.

Back in the dim and distant past, long before Windows and Mac, even before DOS, when the ASCII code was created they intentionally defined two codes for 'End-of-Line': CR and LF.

Do you remember how early typewriters and printers worked?

One action to roll up the paper one line (=LF), another action to move the carriage or the print head back to the start of the line(=CR). Both commands were necessary.

Then Linux (did Unix this too?) implied the CR code when there was just a LF. But this was only internally. In communicating with any printing device the 'LF' was expanded to the full 'CRLF' sequence!

To create a vertical line of e.g. '*' somewhere on a page with no other text, you had to move the print head to the starting position and then only repeat this sequence: '*BSLF' multiple times.

IIRC, the old apple OS did it not like Linux but implied a 'LF' when there was only a 'CR'.

I never had to deal with files from a TRS-II, Commodore PET or Atari, so I don't know about them.

I know IBM mainframes used their own encoding, not ASCII.

HP's systems (the 3000 series, the 250 series and the 1000 real time series) used HP's Roman8 encoding (same control codes as ASCII) and their early Vectra PCs could be switched from ASCII to Roman8 for compatibility with their bigger systems. I analysed text files from a HP 1000, they had CRLF as 'End-of-Line' sequence.

BTW, if you would send a text with only a LF at the end of each paragraph to one of the old dumb printers it would print one line of text and then just advance the paper one line for each paragraph. :)

HM.
(typo edited)

I know IBM mainframes used their o

IBM mainframes use EBCIDIC

https://en.wikipedia.org/wiki/EBCDIC

IBM mainframes use EBCIDIC

I know, but because I never had to cope with this code I forgot the name and was too lazy to look it up.

HM.

One action to roll up the paper one line (=LF), another action to move the carriage or the print head back to the start of the line(=CR). Both commands were necessary.

Then Linux (did Unix this too?) implied the CR code when there was just a LF. But this was only internally. In communicating with any printing device the 'LF' was expanded to the full 'CRLF' sequence!

Historically correct, and understandable, due to the fact that the earliest printers available during the first days were teletype printers. Those machines required separate CR (carriage return) command, and a LF (line feed/paper advance) command for each line of print. I used to work with radioteletype and if during a weak signal or static condition one of those CR/LF commands was missed, the machine print was either overprinting or jammed at the carriage stop until a following CR/LF was received.

A basic toolkit item in any text-munger's repertoire is a 'translation' app to convert text file line endings from Windows-Mac, Mac-Windows, etc etc. Many 'Swiss Army Knife' type text editors included the functions in their menu choices. I still use BBEdit (mac text editor) to 'clean' a text file, removing hard line returns and other Windows cruft, to produce a cleanly-flowing Linux/Mac file for web page output.

Again, to all: a clean text file uses UTF-8 text encoding, and LF (Linux-encoded) paragraph endings. Using the other, older code outputs is just asking for headaches.