Forum: Author Hangout

I hate justified text on a small screen and I do most of my reading on my phone, and now most people do.

I switched to justified text only because that's how the traditionally published novels are.

It makes sense for print since the margins are uniform on the printed page, but I never thought to do it for an ebook until I checked out the traditionally published novels.

The paragraph indenting (first line) on SOL is not an author-set style. On the site here first paragraph indent is under the reader's control. You can set your style to read stories with the first line indented as much as you want. All readers can, but as an author you can't force it.

Except, that's a literary strategy employed by many, including several SOL authors. It's NOT a 'first line' indent, as typically the first line is NOT indented. Instead, it's to designate information from an alternate source (ex: a handwritten note, a posted sign, or broadcast speech like a radio program). In other words, it's dialogue from someone who's NOT present in the story, is treated as 'quoted text', and is set apart so readers DON'T confuse it for dialogue from the regular cast members in the scene.

It's a handy visual shorthand that, while typically not explained in detail, is quickly absorbed by readers.

As Switch suggested, I typically include both indented text AND separate it with extra blank lines before and after the associated dialogue. That deftly avoids you're cutting the formatting.

It's NOT a 'first line' indent, as typically the first line is NOT indented. Instead, it's to designate information from an alternate source

Do you mean blockquote? I believe SOL supports blockquote. Although I don't know if that will work if the file was a docx.

As Switch suggested, I typically include both indented text AND separate it with extra blank lines before and after the associated dialogue.

That's not what I was talking about.

When I write a story to publish as an ebook, I indent the paragraphs except the first in a chapter or scene change. There are no blank lines between paragraphs.

When I write a story to post on SOL, I don't indent the paragraphs but put a blank line between the paragraphs.

I was wondering if I could write all my stories the same way (indenting with no blank line) and then, if it's a docx file, have SOL convert that to no indenting and add a blank line between paragraphs.

By-the-way: on SOL there are no blank lines between paragraphs but paragraphs are styled to show a top margin. When you put in a blank line it just marks a new paragraph for the converter.

I didn't know that.

Then if the docx paragraph is indented, why can't the SOL converter just mark a new paragraph for the converter like it does when it encounters a blank line?

What I don't want is, if I indent paragraphs without the blank line between them, for it to end up as one huge paragraph. That's why I put in blank lines when submitting to the SOL Wizard.

Maybe Lazeez will make a change for the docx format where he also accepts a paragraph indent as a marker for a new paragraph. That would eliminate the need for an extra blank line and leave the docx the same for a conversion to an ebook.

That's exactly what I'm asking for.

Then you better make sure you don't miss the indention on a paragraph

Word does it automatically when I hit the return (assuming the paragraph I'm on has the indent).

I don't indent the first paragraph of a chapter or new scene. But they're proceeded by the chapter name (which has a blank line after it) or the centered * * * * (which has a blank line before and after it).

I don't indent the first paragraph of a chapter or new scene. But they're proceeded by the chapter name (which has a blank line after it) or the centered * * * * (which has a blank line before and after it).

Again, using SOL rules, EVERY paragraph has an header between paragraphs (bland line & the next paragraph). Posting .docx should use your own guidelines, but SOL may force their traditional paragraph rules on EVERY line, regardless of how it's formatted.

Future docx support on the beta site will not even allow images embedded in text (it's a horrible job importing images from docx). It will simply do mostly text conversion, create a TOC and embed the cover that you submit to create an EPUB file.

That makes sense. One benefit of ePubs is that the included images are composed of embedded zip files, which means repeated images (like graphic section breaks) aren't duplicated, making the images much smaller, plus it doesn't take extra processing by the author (Calibre packages the included images for you).

But if the SOL .docx processing doesn't include the document's formatting (inline instead of style based formatting), then there's really NO use in using it, it's just a more convoluted way of submitting html! (I just tried submitting a couple .docx single chapters, just to see how they processed.)

It would amaze you how difficult some find converting their Word documents to html.

Trust me, considering the amount of time I invest regularly cleaning up Word's html code, I can easily believe it. What's more, you seamless processing of my clean epub works MUCH better than ANY site's conversion process!

I would agree. I suspect that Lazeez will maintain the look and feel of the current format. It appears to me that Lazeez has been saying, he will convert the content format defined by the poster's .docx files to the format used by SOL. He also said, only certain .docx codes will be converted. I don't recall him saying the converted .docx file content would have the same appearance when it is posted.

he will convert the content format defined by the poster's .docx files to the format used by SOL

Again, that's what I expect, too. But what happens when the docx file indents paragraphs and does not have a blank line between those paragraphs?

The SOL format is no indent with blank lines between paragraphs. That's fine. I like it like that as a reader.

The question is, do I have to format my docx like that or will the converter get rid of the indent and add the blank line when it sees the indent?

Either can be detected and converted to the SOL format of a blank line between paragraphs and I suspect that is what Lazeez will do.

I'm hoping so. It would be the end of having to do things differently.

For example, if I'm working on a novel I use Word's italics. If I'm working on a story for SOL I put the < i > before and after the italicized word(s).

Now that SOL will support docx files, I can use Word's italics all the time (and SOL will convert it when it's an SOL story).

I would like the same for paragraphs. If I'm writing a novel, I indent the paragraphs (all but the first one in a chapter and after a scene break). If I'm writing an SOL story I don't indent and hit Return twice for the blank line. It would be nice if I could indent the paragraphs all the time and let SOL do it's thing to remove the indent and add white space between paragraphs.

For example, if I'm working on a novel I use Word's italics. If I'm working on a story for SOL I put the < i > before and after the italicized word(s).

This is why I separate my layout from my markup, if I can use those terms. I write in a text editor (BBEdit) which is extremely lightweight and doesn't care if I have my entire series open at once. It supports folders and hierarchies, making organization easy. I use only a few of the basic SOL markup indicators (_, *, {tt}). This allows me to do literally anything with it.

When I need to create an eBook, I run a bash/zsh script to turn those markups into markdown, then import into Scrivener which has all the layout and formatting tools, and I've created a custom set for my novels. The process of going from the lightweight text editor to the ePub is literally less than two minutes, plus the time to generate the ePub.

BBEdit is free (if you don't need the advanced features) and has fantastic search and replace features, including 'grep' style search and regular expressions. If you're a coder, it has an amazing set of coder support (folding, color-coding, git, etc).

Of course, I'm on a Mac, so YMMV.

I write in XML with CSS classes in Vim. Then I use Groovy scripts to translate it to whatever format is used wherever I'm posting to.

I translate to full SOL markup format when posting here. Lazeez's markup preview tool was invaluable in helping me debug my script.

I translate to full SOL markup format when posting here. Lazeez's markup preview tool was invaluable in helping me debug my script.

The only thing you're missing, using this approach, is your ability to include publishing marks (em-dashes, ellipses, and other language features), which most SOL authors would NEVER need.

I've always been one to push the limits, to see just how far I can stretch them, either with plots, formatting or writing styles. I'm currently uncovering LOTS of unforseen 'bugs' in Lazee's beta code (much to his chagrin).

Now that SOL will support docx files, I can use Word's italics all the time (and SOL will convert it when it's an SOL story).

I would like the same for paragraphs. If I'm writing a novel, I indent the paragraphs (all but the first one in a chapter and after a scene break). If I'm writing an SOL story I don't indent and hit Return twice for the blank line. It would be nice if I could indent the paragraphs all the time and let SOL do it's thing to remove the indent and add white space between paragraphs.

Correct. That's precisely what it does (preserves your in-line formatting).

Correct. That's precisely what it does (preserves your in-line formatting).

You contradicting yourself (this post and previous post).

First you said it will ignore paragraph commands (such as indent).
In your second post you said it preserves your in-line formatting.

In the future, If I submit a docx file to the SOL Wizard with:

[indent]xxx xxxx.
[indent] x xxx.

Will it show up on SOL as:

xxx xxxx.

x xxx.

or

xxx xxxx.
x xxx.

You would probably be better served with a line of ***

I'm not referring to a scene change.

I'm talking about paragraphs. Today, I write my SOL story in Word. I don't use italics. I put the < i > around the italicized words. I don't indent paragraphs. I put a blank line between them (hit Return twice). Then I save it as txt and submit it to the Wizard.

Of course when I write a novel in Word I use all of Words formatting (italics, paragraph indents without a blank line between them, etc.).

So I have to do things differently depending on whether I'm writing it for the SOL Wizard or, say, input to Calibre. I was hoping I could do it the same for both and have the new SOL converter convert it to the format SOL requires.

It sounds like that won't happen so I'm not sure what the advantage is for having the docx converter.

Of course when I write a novel in Word I use all of Words formatting (italics, paragraph indents without a blank line between them, etc.).

As long as you're only italicizing indiividual words or lines, that'll continue to work. What won't is if you use a specially defined italicized paragraph style.

"In-line" formatting is formatting surrounded by < i>< /i> commands. "Style-based formatting" is when you predefine a particular paragraph type.

It sounds like that won't happen

The best way to find out is to post a chapter by submitting a .docx file and see what happens. If you don't like it, you can always resubmit the chapter using your former method.

You contradicting yourself (this post and previous post).

First you said it will ignore paragraph commands (such as indent).

In your second post you said it preserves your in-line formatting.

Sorry, "in-line" formatting means formatting "within the line", as opposed to "Style" or paragraph formatting. Since I tend to adapt practices based on publishing industry standards, I often use publishing terms.

But as others have noted, it displays on SOL depends entirely on how you have SOL set up to display pages, as it's user selectable. But the SOL default is #3.

@Gauthier

Adding an empty [para] would be removed by most editor as an error.

The Industry (html) standard for that is to use "< p>& nbsp;< /p>".

The question is, do I have to format my docx like that or will the converter get rid of the indent and add the blank line when it sees the indent?

Having tried it, the .docx (it doesn't accept plain .doc files) simply ignores ANY paragraph commands other than center/left/right alignment.

It appears to me that Lazeez has been saying, he will convert the content format defined by the poster's .docx files to the format used by SOL. He also said, only certain .docx codes will be converted. I don't recall him saying the converted .docx file content would have the same appearance when it is posted.

I ran a test, submitting an existing chapter using a .docx file, and you're right. As I mentioned previously, it basically acts as an alternative to submitting via html (i.e. it accepts html's inline formatting, but ignores ALL predefined formatting).

Thus, for me at least, there's no reason to NOT continue submitting via html (which still offers more options than submitting via text).

which still offers more options than submitting via text

I have been submitting in HTML format. I posted the HTML files Word created without editing them.

I have been submitting in HTML format. I posted the HTML files Word created without editing them.

The comment was about you, merely a reflection on how much you can accomplish via html (beyond basic inline formatting). As for editing html files, I've been doing this for a while, and learned long ago that Word adds a bunch of junk in their html. In order to understand what it was including, and how to circumvent it, I started examining it. What I learned was shocking, and I've never looked back on custom-building my ePubs (it's extremely rare when one my mine fails a basic epub check).

For most, it's an unjustified expense, but because I'm so particular about what I do, the cleaner, smaller and more efficient code is definitely worth it.

Word adds a bunch of junk in their html

I think we're talking about SOL here, not creating an ebook. It doesn't matter how much junk Word puts in the HTML. The SOL Wizard strips it out.

I think we're talking about SOL here, not creating an ebook. It doesn't matter how much junk Word puts in the HTML. The SOL Wizard strips it out.

I was explaining WHY I'm so obsessed with 'cleaning up' my html files, because REP had commented on it. More than anything else, my obsession is designed to help my documents survive 'converters' which aren't as well implemented as Lazeez's are. The fact I keep stretching the limits means I'm fairly well-informed on overcoming various problems in publishing and posting online. Nothing more.

Maybe Lazeez will make a change for the docx format where he also accepts a paragraph indent as a marker for a new paragraph. That would eliminate the need for an extra blank line and leave the docx the same for a conversion to an ebook.

The new .docx code which Lazeez implemented (at least on the beta site) does exactly that, as I can customize the definition of individual lines (Paragraph Styles). However, no one seems to be clear on what takes precedence in the conversion, the SOL paragraph spacing or the newer .docx conversion. Someone needs to experiment.

The new .docx code which Lazeez implemented (at least on the beta site)

I thought the new docx was SOL, not bookapy.

It was supposedly based on the beta site's new .docx code. I was hoping they operated similarly, but apparently it's just a more complicated, more error prone and messy way of posting as html.

I used to go to a store that sold old software at discounted prices. I've bought some of my current software at very reduced prices on-line.

I did a search and found this, which might help you out.

https://www.ebay.com/itm/302235394155

I used to go to a store that sold old software at discounted prices.

I once worked for a company that sold servers and other computer stuff. I was given a tour that included an area where they had vending machines that sold software. It was in an alpha state. The company was looking for venture capital to kick off the business. I don't think they got it.