Forum: Author Hangout

(two or more instances

Can't be two. I use two hyphens "--" instead of an emdash and it doesn't convert it to a horizontal line. (At least I sure hope it's not doing that.)

Straight from the formatting guide. https://storiesonline.net/doc/Text_Formatting_Information_Guide#gen

If that's the case, a lot of my stories are trashed.

how about if they insert a page-break code at the closest point before that character/word limit.

a bit more than that will be needed, because I currently break up my stories into posting parts on a similar basis. However, the current Wizard process is such it will join multiple parts if submitted together and then choose it's own breaks. So I have to submit each part as a different chapter for posting on a different day to stop the auto-join activity.

Submarine races? Showing your vintage - my folks used to joke about that.

It was a running punch line for decades in Chicago (around Lake Michigan--which have never had many submarines in the first place). As far as I know, it was never a popular expression anywhere else--except when it was borrowed (i.e. it's got less regional usage anywhere else).

I've heard it in Milwaukee. I think it's something that is most popular in coastal areas around naval bases. There are a couple of naval bases on the great lakes including a Naval training base in the Chicago suburbs.

I heard the term all the time in Chicago, despite having lived around Navel bases for decades, I've never heard the term used around military bases. In Chicago, it's an ironic title, since there are NO submarines anywhere. On the East or West coast, it's a meaningless phrase, as you'd never know if there were submarines there or not.

That you can't see the submarines is the point. It's used as a pickup line for invite to go make out or a "make-out point" type reference.

The point is, if there's any chance that there may be actual subs, the joke falls flat. It's only funny in an ironic sense, such as when you live on a lake with no access to the ocean (where subs live). Even then, the joke is only funny if the girl is so stupid they don't catch the joke. (It's pretty mean-spirited.) Typically, a group of guys will spin in on a couple new girls, and everyone twitters over how stupid they are--and no one makes out with anyone!

Submarine races?

Don't know about in the USA, but down here in Australia I've heard of submarine races used two ways:

1. A section of the harbour or ocean where submarines regularly travel on their way to and from their base - thus it's a lane of restricted access.

2. Some sort of alcoholic drinking contest uni students got up to in the 1970s. I never did learn what it was they drank, but it was a large amount and they contested head to head to see who could drink it the fastest.

Who knows how many ideas it will take before the problem is solved.

In a way, it is solved. I manually break the story into separate parts where I want them broken, and then load each part as a separate chapter to be displayed on a different day. I little bit of work, but it works.

a bit more than that will be needed, because I currently break up my stories into posting parts on a similar basis. However, the current Wizard process is such it will join multiple parts if submitted together and then choose it's own breaks. So I have to submit each part as a different chapter for posting on a different day to stop the auto-join activity.

Ernest, Lezeez, I've got a specific question about this functionality. I've got two incredibly short chapters which I combined into a single SOL file. How does the SOL wizard handle dual { p } commands? Does it list them both in the index, combine them, or create separate chapters. Also, should I do anything specific when I post the file (coding wise, rather than simply notifying the Admins.)?

As for why I created such short chapters (both under 1,000 words), the reason is because they deal with separate issues and it made sense creating separate chapters in book form.

Ernest, Lezeez, I've got a specific question about this functionality.

You'll probably have to wait for Lazeez to answer this one, I don't actually use the { P } command itself. Also, I manually create the ToC I provide at the start of my stories.

However, I can tell you the system will automatically cut a file where it find a what looks like a heading that starts with the word Chapter - even if the first word of a paragraph is Chapter it will see that sentence / paragraph as a title for a new chapter and cut the file there. That's why I work hard to avoid suing the word anywhere.

How does the SOL wizard handle dual { p } commands?

Are you trying to put a blank line to start a new scene?

If I remember my HTML (which I don't really), it drops consecutive < p > commands leaving only one. I think I used to fudge it with using consecutive < br > space < br > commands, or maybe the space was actually the nbsp.

But I don't use the blank line technique when reading on a screen. It works great on a printed book, but I find it gets lost on a screen. I use four asterisks centered for a scene change on SOL and my ebook.

But Lazeez will give you the correct answer.

If I remember my HTML (which I don't really), it drops consecutive < p > commands leaving only one. I think I used to fudge it with using consecutive < br > space < br > commands, or maybe the space was actually the nbsp.

No, Lazeez finally explained a short time ago that the Admins use { p } to define chapter heads, since they use < h1 > to format Story Index pages. That's completely different than the < p > html command. Since he revealed that, I've been very studiously coding my html submission files that way to save the SOL admins. a little more time in processing my files (I figure it's the least I can do).

In this case, I'm using two, non-consequtive { p } commands to load two chapters in a single file, but I wasn't sure what effect that might have on the resulting file. I'm assuming that it leaves two very short chapters, just as if I submitted the two chapters separately (i.e. no real gain by combining the chapters).

The easiest solution in my case, it to simply combine the the two chapters, drop the extra { p } command and post it as a single chapter, but then my book and my online story chapters don't correspond. That might cause reader confusion, though it doesn't really change the story at all.

Or how about using a chapter title like Ernest does. The title might be a little insurance for possible variations.

@Ernest

So if you want to load a large file and have the system break it into chapters, just have each chapter title start with something like Chapter xx - ....

I tend to put more effort into coming up with detailed chapter titles. To make room for longer titles, I've done away with the traditional "Chapter Twenty-Seven: Gone to the Store". Instead, I simply list is as "27: Exploring Produce in the Vegetable Aisle".

to load two chapters in a single file

CW, when I first uploaded Flames of Life I made a mistake. The story is in three segments and is meant to look like two books by the main character and then the main story. To show that, in the first draft I had the first of his books broken into three chapters with titles starting with the word chapter. It was within the cut limit and I intended it to show as a single post. Thus I lodged the file as one post, but the system automatically cut it into three at each heading where I had the word chapter as the first word on the line. After a few emails with Lazeez, I removed the word Chapter from the headings, resubmitted, and it loaded as one big file, the way I wanted it to do it.

So if you want to load a large file and have the system break it into chapters, just have each chapter title start with something like Chapter xx - ....

The {p} specifies a chapter header for file division. It can't be on its own, and whatever follows it is set as the part's title in the database.

Careful though, if it's present in the text, whatever is before the first one gets ignored.

OK, that's pretty clear. But what happens if I have two { p } commands corresponding to two separate chapters in one document? Will it process files correctly, or do I need to either split the file apart or subsume the chapter?

I see a p in brackets of any sort

now that's called damn good aim.

By the way {p} is for 'Partition' not 'paragraph' so it's NOT the equivalent of < p >.

Thanks, Lazeez. That's what I was assuming, but I wanted to be sure before I started submitting combined files.

I started using { p } when you explained the moderator tasks some time ago. I was writing a story with different sections, so you suggested I use { t } tags, and then { p } tags under those, so I've been following that protocol ever since.

I hate to suggest it, but the SOL submission engine seems to have issues with large blocks

from:

https://storiesonline.net/author/posting_guidelines.php

Chapter/Part/Story length:

Due to various technical reasons, we try to keep the length of each file served from the site below 58,000 characters (approximately 12,000 words). Any story or chapter longer than 58,000 characters will be served in pages on the site, just like in a book. The page breaks are created by a script, so you never know where your file will be divided. If you don't like the idea of page breaks in unexpected places, then divide your own text into smaller chunks.

Which is why I always review new chapters on SOL myself after posting.

My problem, is that I'm too clever by half. I typically post after 12:30, to ensure my entry is the first in the next day's queue so it'll stay up for as long as possible. The problem, is that I rarely wake up in time to see the story when it first posts, only making it downstairs to my office around nine or ten. If there's an issue, I'll typically have several complaints, which again, are only a few of the readers I'm potentially losing.

I go through and beak the story up into posting chapters, and post each separate to the rest, thus the wizard can only screw up one at a time. By making sure the posting chapter is within the limits it reduces the risks of a screw up.

be sure that text files are in UTF-8 coding, and that html files have the utf-8 code entry in the header.

I thought for SOL it's supposed to be charset=windows-1252.

No. I switched the site's engine to UTF-8 in 2001.

UTF-8 doesn't use values 128-159.
133 = horizontal ellipsis
151 = em-dash

I guess that's why when I post a story to SOL I use "--" for the em-dash and 3 dots for the ellipsis.

EDITED TO ADD: btw, I have no idea what the above really means. I got it from a site comparing the different charsets. My main problem, I think, is when I convert my Word doc to a Word txt file. The em-dash does not end up being an em-dash (I think it converts it to a hyphen). I forget what happens with the ellipsis. That's why when Word automatically converts "--" to an emdash and "..." to an ellipses I undo the replacement. So it's way before the posting step on SOL.

There is also a setting where you can type two hyphens or three dots, and it will auto-convert to em-dashes and ellipses

gray,

See what I added to my previous post about this.

So your Word conversion from .doc to .txt converts those characters to text substitutions

When I point the SOL Submission Wizard to the file to upload (via the browse), I thought it had to be a txt file.

Wouldn't it be easier to go into the auto-correct settings and tell it not to replace them in the first place?

I did that one time, but changed it back. Everything I do with Word, other than SOL, needs the real em-dash and ellipsis.

I've never 'pasted' a file into the wizard; normally I upload, using the .md.txt markdown formatted text option. In the past I've uploaded .html files. Never had a problem, BUT having said that, be sure to follow the upload instructions. Example, be sure that text files are in UTF-8 coding, and that html files have the utf-8 code entry in the header. Stuff like that.

I almost NEVER post using UTF-8 files, and I've never had a problem. The only time I do use UTF-8 is when I've got 'special characters', most often foreign accent marks, rather than 'standard' publishing marks.

I'm not sure why my windows-1252 files post successfully, but the problem with UTF-8 is that you have to code multiple things by hard coding values (i.e. " & mdash ; "). I suspect the em-dash is a bad example, but I know with foreign lanugages, I've got to convert from text to html coding of each character (performed by copying from my 'html coding' window to my 'display window'.

@Switch

That's why when Word automatically converts "--" to an emdash and "..." to an ellipses I undo the replacement.

It's easier simply disabling the 'auto-replacement' function, as well as the 'auto-smart quotes' feature. Otherwise, you'll keep forgetting to convert files.

By manually encoding em-dahses as & mdash; you basically remove UTF-8 and you create a universal file that doesn't need any specific encoding. windows-1252 encoding has em-dashes and you shouldn't need any specific conversion.

By the way, Lazeez, your comment about not being able to process 'Windows character sets', as you say, it's a standard set of characters. As a result, browsers and other tools automatically translate and displays the correct text, just as the SOL engine appears to. It essentially says, 'these are windows' tags, but here are the translations for your own computer type'.

That's why I prefer it over other character sets, because it forces the other programs to convert the characters, rather than only displaying Mac or Linux formatting.

@richardshagrin

I knew I wasn't smart enough to be an author. I read all this stuff to make sure I am not missing any jokes, but it makes my head hurt.

You can ignore most of it. Many of us here come from tech backgrounds, so we understand these things. As we've discussed elsewhere, some of us use 'publishing marks' (em-dashes, ellipses and smart quotes) to make things like interruptions and hanging pauses clearer, but SOL handles them fine either way.

deal with tags & things to produce Kindle-ready files and stuff like that.

I don't worry about that, and simply import my .odt file into Calibre to produce the e-pub file for selling. It will also make the kindling files (no typo).

I look forward to the time when I have to deal with tags & things to produce Kindle-ready files and stuff like that. Those years of hand coding HTML & JS back in the mid-90s will come in handy! ^_^

In fact, Amazon doesn't really allow you to edit the finished Kindle files.

No, but I understand that producing a file that is ready for conversion can be slightly problematic.

That's why I submitted an epub to KDP. I wanted full control of the XHTML.

That's why I submitted an epub to KDP. I wanted full control of the XHTML.

How well does that work? I'm still reluctant about doing that, since it's still "Beta only" and I'm not sure the full epub functionality is supported.

If it's reliable, and works, I may consider submitting epubs instead of WORD files.

since it's still "Beta only"

It is? I thought it was beta on Smashwords, but not on KDP.

As far as I know, it worked fine. I didn't actually read the whole novel after publishing it (but I did skim it). I only used basic HTML, though. I wanted to use blockquote in one instance but shied away from it. I thought the simpler it was, the more chance of not having problems.

As far as I know, it worked fine. I didn't actually read the whole novel after publishing it (but I did skim it). I only used basic HTML, though. I wanted to use blockquote in one instance but shied away from it. I thought the simpler it was, the more chance of not having problems.

In my epub files, I've been focusing on 'proportional formatting' (i.e. width="75%"). blockquotes are problematic, as I've pointed out before, because Kindle files typically reduce all blockquotes to a single space, which is virtually invisible to the casual reader.

In that case, I prefer using Style definitions, where "Indented text" is defined as being indented by "2em;" or two character widths, whichever font/font size the reader selects.

I wasn't sure whether such advanced epub features were implemented yet by Kindle, and thus hadn't even tried them yet (though I have been using the Style guide indents).

Either Amazon supports epub or they don't. Thus I'd either use the features--and learn what works--or avoid epubs altogether.