Forum: Author Hangout

I keep the full story in one master document. When preparing to post a chapter, I copy that chapter to a separate document. When it's ready to post, I save it as an html file then post that file.

Master document is key; posting individual files ditto. I compose in Word then run a couple of global replaces for SOL formatting (blank line between paragraphs, remove Word's autoformatting for quotes, etc.)

Final edit of the single file in Mac's TextEdit app, then copy and paste into SOL's "Let me paste my text" box. My formatting for SOL is pretty basic, so I use SOL's tags for that.

All corrections and edits as I review and revise to the source document first. You've thus always got an authoritative source.

bb

File formats accepted for submission of works through the site are: Plain Text (.txt, .asc) and HTML files. (All open formats, no proprietary formats are accepted -- No Word, Wordperfect, MS Works, AppleWorks, or Lotus Word) If you need to submit styled text like italics and bold, convert your document to HTML. All the popular word processors support one of these two.

If you paste into the Text Box you can copy and paste direct from one of the forbidden file formats.

Stay away from any fancy formatting and you won't need to manually edit the .html or .txt.

You can do it that way if you want, but my main aim is a well Presented print book and e-book with version for SoL coming in behind that. So my drafts and master have a lot of formatting in them. SInce SoL allows for that formatting using the Tagged Text codes I do it that way. And, yes it's a more than .txt allows, and basic .html code won't cut it in the print and epub versions.

You can do it that way if you want, but my main aim is a well Presented print book and e-book with version for SoL coming in behind that. So my drafts and master have a lot of formatting in them. SInce SoL allows for that formatting using the Tagged Text codes I do it that way. And, yes it's a more than .txt allows, and basic .html code won't cut it in the print and epub versions.

In my case, I submit html (to SOL) because I'm already using html to post to my website and ASSTR, thus it's natural to use that format over having to format each chapter from scratch. There's actually little custom formatting for each destination (I remove paragraph types, although SOL strips those out anyway), and I add the { p } flag instead of expecting the Admins to convert my < h1 > tags. Beyond that, there really isn't much cleanup. However, when I post to my website and ASSTR, I add a LOT of extra bells and whistles, simply because they allow for features and customization. In the end, it benefits the reader, and also helps me promote my work.

Exactly, although I suspect I do less formatting than you do.

I think I do more formatting than most people do, due to the issues I've seen with the various e-book readers.

I use italics, bold, colour, and blockquote in the text of the body, plus italics, bold, font size, and colour in the headings.

I also use four headings, all are centered on the page:

Title page is 32 point font text in green text and small capitals.

Chapter in red and 18 point font.

Sub-chapter in blue italics and in 14 point font.

Section id in bold and in the 10 point font of the text.

The font type and size is stripped out for the SoL version to allow the user's display setting full control. Also the title page and copyright page is removed.

Thus, for SoL, the Tagged Text commands I use are: center, red, blue, italics, bold, block, and the BR line return command is used in some things like lists and poetry to have no space between the lines.

edit to add: the finished SoL product is very close to the original.

typo edit.

I think I do more formatting than most people do, due to the issues I've seen with the various e-book readers.

Ernest and I are probably the two most format-intensive authors here. But I tend to go for fancy graphics, exotic fonts and cute buttons ("Prev" and "Next" links), while Ernest prefers fitting the text onto the page so they break correctly.

However, the only text formatting I use are italics, occasional bolding (mostly restricted to styles like "Big Text" or "Bolded Centered") and indents. After struggling with Amazon tossing all blockquote commands, I eventually gave up on the html/epub command, instead relying on Style definitions to indent text by 3em; (3 character widths using whichever font the reader prefers). For SOL, I change the indent back into blockquotes since there isn't any other options.

So far, I haven't heard any feedback, either positive or negative, concerning my use of various fonts and graphics (ex: for section breaks), so it's probably a wasted effort, but they help create a uniform 'feel' for the story, and add value beyond the Free stories so abundant in most ebook sites.

My suggestion wouldn't work for someone looking to publish e-books or dead tree. However for an author only posting here on SOL, it's the simplest way to handle it.

Correct, and that's the case with some, and I hope they take it up.

If you paste into the Text Box you can copy and paste direct from one of the forbidden file formats.

With, however, sometimes rather erratic results. Even text that displays correctly in the Format Previewer does not necessarily display well when posted. I did three revisions to Chapter 1 of before it came out right, and thanks to the moderators for bearing with me.

So now I strip out everything down to the bones, and then add whatever formatting I need.

As for the separate files: They get lost sometimes. If your text is too long for the Paste box then sure, go with the attached file. Otherwise, why complicate things?

bb

Libreoffice that takes a normally formatted ODF to pump out those files. That will hopefully save me a lot of work in the future.

If you get that going, I'd love to be a tester of it for you.

What I currently have is a tool that takes *.sol files and converts them to either rtf, html or LaTeX files (for ebooks). Currently I'm trying to expand on that by writing a plugin for Libreoffice that takes a normally formatted ODF to pump out those files. That will hopefully save me a lot of work in the future.

Ha-ha. LaTeX is only a 20 - 30 year old print technology, so it's hardly the 'latest' in technology. But epub uses the majority of html code directly (with only a few command substistutions (like replacing styles with CSS definitions, and < br > commands with < br / >)). It's an easy transition to go from html to epub.

My issue with epub, is it takes a massive effort to search and replace, code, format and convert in order to make changes to an already published story (such as when someone catches a typo). Thus I end up creating the epub files, but never using them!

Ha-ha. LaTeX is only a 20 - 30 year old print technology, so it's hardly the 'latest' in technology. But epub uses the majority of html code directly (with only a few command substistutions (like replacing styles with CSS definitions, and < br > commands with < br / >)). It's an easy transition to go from html to epub.

It may be 30 years old technology, but no HTML can make a printed book (or an ebook for that matter) better than one that was written in LaTeX.

@Crumbly Writer

Ha-ha. LaTeX is only a 20 - 30 year old print technology, so it's hardly the 'latest' in technology. But epub uses the majority of html code directly (with only a few command substistutions (like replacing styles with CSS definitions, and < br > commands with < br / >)). It's an easy transition to go from html to epub.

It may be 30 years old technology, but no HTML can make a printed book (or an ebook for that matter) better than one that was written in LaTeX.

Absolutely bang on. No question at all. Sorry, HTML weenies, it's no contest. Yes, there are more bells and whistles with HTML, but whether they improve is in the beholder's eye, and we know what that means...

(Could we argue about vi vs emacs next?)

(Psst. That's a joke. Let's not.)

bb

Absolutely bang on. No question at all. Sorry, HTML weenies, it's no contest. Yes, there are more bells and whistles with HTML, but whether they improve is in the beholder's eye, and we know what that means...

File this in the why-isn't that-not-very-interesting-but-I'll-tell-it-anyway file:

I heard Donald Knuth speak at a memorial service a couple of years ago. Granted, the guy is about 105 years old at this point so we'll cut him some slack, but it was not a compelling talk.

I sat there comparing this kind of rambling wandering narrative to the clean precise simple (well, with a LaTeX or other front end, anyway) program he'd written.

The guy is an artist as well as mathematician/computer guru.

bb

Not so with a TeX/LaTeX document. It would have to be reformatted and a new one generated to resize it for a different page size.

Well, I did note that beauty is in the eye of the beholder. And I probably should have emphasized I was looking at printed material, not e-stuff.

(I speak as an MS Word user who relies on Lulu's conversion machine to produce a clean ePub, which it does. And speaking of converters, let us not speak of the Smashwords abomination.)

That said, here's the massive rewrite needed to reformat a LaTeX doc from Trade Paper (6x9) to U.S. Letter size:

Trade Paper:

usepackage[margin=1.0in,paperwidth=6in,paperheight=9in,marginparwidth=0.75in,marginparsep=0.10in]{geometry}

US Letter:

usepackage[margin=1.0in,letterpaper,marginparwidth=0.75in,marginparsep=0.10in]{geometry}

Done.

I like Sumo wrestlers and ballet dancers. Especially the skimpy costumes on the former.

bb

EDIT: "Weenies" was pretty mean. I shouldn't have used it. I must have been channeling the Republican candidates for president.

(I speak as an MS Word user who relies on Lulu's conversion machine to produce a clean ePub, which it does. And speaking of converters, let us not speak of the Smashwords abomination.)

The secret to decent epubs is NOT to rely on converters. Unfortunately, the time to structure and format the document each time you make changes to a document make it largely impractical for anything other than a 'one-time' conversion from one format to another.

Concerning smashwords, they allow authors to submit epubs (as a separate submission than the other document types), but no one can tell me how they handle updates to both epubs and source files for conversions.

Sumo wrestlers in tutu's and ballet dancers in... sumo _jockstraps?_

To my surprise, the Internet does not know about a female ballet dancer wearing a sumo jockstrap. Nor, except for some creative Photoshop efforts, about a sumo wrestler wearing a tutu.

But you can learn a lot about how a male ballet dancer uses a dance belt.

bb

I speak as an MS Word user who relies on Lulu's conversion machine to produce a clean ePub, which it does.

You may wish to try using Calibre, it's free and it gives a bit more control over the finished e-pub product - Lulu accepts it with no problems - beyond posting a file from the future.

You may wish to try using Calibre, it's free and it gives a bit more control over the finished e-pub product - Lulu accepts it with no problems - beyond posting a file from the future.

I've used Calibre to add a cover to my ePub, because I want the reader to have it and not just see the micro image in their library. Have't tried composing yet.

bb

Have't tried composing yet.

It allows you to import the document and then converts it to the wanted output for you. It takes in .docx as well as .odt and others. I import the .odt file, then I amend the metadata to include the isbn and a few other things, then convert, adding the cover image at the same time.

My Lulu page has a Free book on it about creating an e-pub file using Calibre - I do need to update it, but what's there is good. It's also available free from Amazon, B&N, Apple Stores, Kobo, and Nook.

http://www.lulu.com/shop/ernest-bywater/make-a-good-e-pub/ebook/product-22124365.html

I've used Calibre to add a cover to my ePub, because I want the reader to have it and not just see the micro image in their library. Have't tried composing yet.

I've done a lot of research into editing Calibre code and getting it to behave as you want it to, also in hand coding their internal TOC. If you need any advice, drop me a line and I'll help resolve any specific issues you may have (if I know how, that is).

@DS

MS Office and 'no-nonsense' don't belong in the same paragraph.

Sorry, that's the purpose of the comma, to separate two separate elements. I was referring to M$ Office AND the other 'writing only' tools currently popping up all over the place. I wasn't implying that M$ wasn't complicated, only that there are alternatives to also consider.

@Shrinedrinker

I'd rather use Notepad than MS Word.

Sorry, I understand your point, but I need something that supports Style Definitions, and Notepad just won't fly. OO and LO do, but since I worked in U.S. businesses for decades, I'm more familiar with Office. Hell, I can still hand code indexes, tying specific characters to specific pages in a document! Try that in Notepad. (Not that I do that in my fiction works either.)

@The Slim[e] Rhino 'D

The other thing is recognizing scene separators for the case that people use custom ones instead of *****

You're not the only one. In fact, while I use underscores ("_") in my html, I use graphic line separators in my original source documents. That's why I edit my html documents by hand (to remove both my crap and the crap that M$ inserts into html files).

@Ernest Bywater

Isn't that what the horizontal rule is for??

The horizontal rule has a particular look, it isn't as clean, and it tends to span too large of a space. I used to use it extensively, but never like the results, and have recently been stripping it out of ALL my documents! It produces a soft-focus, blurry line, rather than a clear distinction between sections. When I used it, I'd include 'width="xx%"' qualifiers.

@The Slim Rhino

I use custom markers in my Star Trek Stories that are meant to resemble the early Starfleet Logo (see "I grieve with thee" for reference). I've developed a logic for that, but it's a bit more tricky to code.

I'd do like SOL does, and simply delete anything you don't understand. SOL doesn't accept graphic section breaks only (only allowing graphics at the start of each chapter), so there's no point in including the graphics. If authors want to include it, they can edit your produced file. That's a reasonable solution, rather than trying to account for everything anyone might want to try.

@tppm

If you need a bunch of special effects to carry your story you need to work on your writing skill.

No, we're writing for more than just SOL (which doesn't support it anyway). For a printed volume, graphics provide a nice contrast to text, and helps justify the higher cost of the books. Take a look at many published books, and you'll see a variety of graphics (especially in the hard-bound, or 6"x9" volumes, which is what many of us are publishing in).

The horizontal rule has a particular look, it isn't as clean, and it tends to span too large of a space.

I don't use the actual Horizontal Rule command, so I can't speak to the last half of the sentence. However, for a major scene break within a chapter where I don't use a section header I use a centered half line long underscore line as my version of the horizontal line and have a blank line before and after it. I think it looks very clean and makes the break very clear.

I don't use the actual Horizontal Rule command, so I can't speak to the last half of the sentence. However, for a major scene break within a chapter where I don't use a section header I use a centered half line long underscore line as my version of the horizontal line and have a blank line before and after it. I think it looks very clean and makes the break very clear.

I do the same thing. It's a much nicer look than either the html horizonal line command < hr >, or "* * * * *". It's simple, works on any device, and is clear in it's interpretation.

BTW, when I encounter a web page that won't resize to fit a chosen browser window size, that page is a failure; I close it and don't go back. It fails proper HTML/CSS standards.

I wouldn't be surprised to find the page is coded all in javascript or the like instead of html.

Next smart remark?

"Would you believe, I was that close, 99?"

"Missed it by that much."

put it down to dementia after 50 years.

Thanks

GB,

We have different aims, and thus, we have different processes to suit our personal aims. The strength of a forum like this is we can have a discussion where we both state our processes and other can see them and choose to do what I do, or what you do, or pick something in between. I'm glad that's the way it works.

Thanks for sharing the process.

typo edit

We can make up our own acronyms. Super Women And Girls?

On the topic of reader feedback : Shit We All Got. ;)

The strength of a forum like this is we can have a discussion where we both state out processes and other can see them and choose to do what I do, or what you do, or pick something in between.

What's more, as the newer authors read these comments, they'll learn who specializes in which specialties (formatting, publishing, posting to alternate sites, etc.). Thus, if they decide to branch out and try something new, they'll know who to ask about it. That's worth a lot in itself, and only costs you a few endless posts containing endless details no one cares about. 'D

@graybyrd

We were on the ground floor of so-called "Desktop Publishing." Our weekly newspaper began using a series of Apple Macintosh computers and early-day DTP software including PageMaker, Ready-Set-Go, and Quark Express. It was a profound revolution, which I'm quite confident to say that very few people (including most on this forum) can fully appreciate. It was equal to Gutenberg's idea of movable, reusable type.

I worked for years using Quark and PageMaker. Quark was wonderful because it allowed kerning of individual characters. Now, when I do graphic chapter heads, I'll often hand kern fonts which don't feature it in Photoshop (talk about obsessive control!).

So go figure ... how the hell do we produce "pretty-print" output for all that?

Wrong! Using basic html, you use relative positioning in your Style Definitions. Thus it won't matter what size the font is, or even which font is being used. The positions are relative, instead of fixed by set distances. I indent my first line of each paragraph by 2.5 characters, and my indented text by three characters. What's more, with responsive web design, the same text displays on any size device. Hell, most devices automatically adjust graphics to fit the device display, and if they don't, I set the display percentage each chapter takes on the page, which forces it to adapt to each display.

Ernest and I regularly argue over his need to fit paragraph orphans (left over text spilling over onto a spare page), but he only does it for print documents where you have more control. However, for a long time, he insisted on duplicating that control by only publishing using pdf, which display an exact copy of the print document, but displays terribly on smartphones!

few endless posts containing endless details no one cares about. 'D

CW,

I've got to thin books I published and put out as total freebies that explains all this. I even go to the trouble of selling them for zero dollars on Amazon, iTunes, B&N, Kobo, and Nook _ I've had several people email me and thank me for making available the information they need to understand what they want to do in self-publishing. This way I can avoid a lot of them emails, because I already have ti out there.

However, for a long time, he insisted on duplicating that control by only publishing using pdf, which display an exact copy of the print document, but displays terribly on smartphones!

CW,

The only reason I put out PDF e-books for so long was I couldn't find a way to put out a nice looking e-pub that was worth the effort. When I did find one, I was fast to swap over to it. But I waited for a good process instead of jumping on the first rough nag that went by, like many did.

The only reason I put out PDF e-books for so long was I couldn't find a way to put out a nice looking e-pub that was worth the effort. When I did find one, I was fast to swap over to it. But I waited for a good process instead of jumping on the first rough nag that went by, like many did.

Understood, that's why I said: "However, for a long time, he insisted on ...". I was providing a background on your fascination with formatting. Mine goes a bit farther back, starting with early desktop publishing in the business world made worse with infinite possibilities made possible with endless technology. 'D I like to see what I can do, and I figure it adds to the complete reader environment.

@graybyrd

CSS and style defs, right. I agree. That's my "Phase III" for doc production. First, the draft document. If it needs to be structured, I'll do that with document heading, meta information, section heads, subheads, etc. The markdown for this more complex draft will be more inclusive, such as graphics and tables and links and references.

That's why I do my formatting upfront. I use each of my existing books to create my next, adding to it as I continue. I use a standard set of Styles (Normal, FirstParagraph, Indent, Centered, Centerbold, etc.) which match my pre-existing CSS definitions (html) which I cut and paste into each ePub (since they don't allow external look-ups).

Thus I do very little actual formatting, instead selecting from my predefined list which ensures I have a consistent look and feel to my stories. Where I go overboard, is the application of graphics. I started out by applying custom fonts on my covers, and then including them as chapter headers. Since licensing 'embedded fonts' is prohibitively expensive and problematic, I instead use 'pictures' of each chapter title in a particular font. That's more effort than most authors are willing to do, but it helps justify my higher prices, and differentiates my books from the hundreds of thousands of FREE books available everywhere you look.

>boring history, but then those who hope to do well with ePublishing would do well to know the history, the development path, and what works... and what doesn't... and to understand the difference.

The problem is, for most readers/authors, it's uninteresting detail. If and when someone decides to expand their expertise, they simply won't care. Once they do, it's better to have someone to reach out to rather than continually beating them over the head with it (part of my 'push/pull' philosophy, though I counter this by repeatedly detailing what I do.

PAW=>paranoid ass wipe (a lower brain stem function)

More common definition: PAW = Post-Apocalyptic World. It's a common SEO term (Search Algorithm Optimization) for books.

I like TeX because you can control literally everything. But of course for the less nerdy people a WYSIWYG system makes more sense :)

No. The problem is, TeX, and especially LaTeX, were too cumbursome to be widely used, and thus it was poorly supported, and never took off. There's a massive difference between a clever idea which never takes off, and someone who figures out how to do it right, so everyone clambers aboard, uses it, and add to and builds on the concepts. Whatever you think of Apple product, there's a reason why Steve Job is seen as a pioneer and visionary. No one else could devise a system as uniform, reliable and usable.

BTW, if it hadn't been for John Warnock and Adobe Postscript technology, including fonts, desktop publishing would never have gotten off the ground. It, and the LaserWriter, were a huge leap forward. 300 dpi resolution print on glossy paper was a huge blessing; we could make camera ready pasteups with it. Not as good as 1200 magazine quality, but for most jobs, and newspaper use, it was very good.

Thanks to Adobe!

That's only partially true. Postscript was around early, but TeX was what made it accessible, and TeX was completed in 1986. IF I've got to write something that needs to look really professional or has a lot of math formulae in it, I would never use anything else. After all, it was specifically designed as a typesetting system.

TeX and LaTeX today remain primarily an Academic system of choice, for good reason. There's a reason why decent built-for-purpose TeX editors, like LyX, had to be written. TeX is NOT a casual technology.

Well, some of my stories were written in vi, so you can probably imagine my geek-level ;) I like TeX because you can control literally everything. But of course for the less nerdy people a WYSIWYG system makes more sense :)

It's a complicated XML based format. Definitely not just HTML. It's documented and everything, and zipped, but a pain in the ass to support for one person with many other things needing attention.

Very true, Mate. But if he comes up with a suitable converter program it may be worthwhile getting his permission to make it available for download from the site for people to use on their own computers to prepare a SoL ready file for you.

Mind you, if the half dozen or so HTML tags I asked about before were accepted by SoL, I think it would solve the issue for many people. It definitely would for me - because those are the tags I spend most of the time converting to the Tagged Text code for a submission.

The only thing that you asked about and gets stripped are the h1 and h2 tags. I can help you by downgrading them automatically to h3 and h4.

Don't worry about. I already use H3 and H4 for other items. Since I have to work the file to include the Tagged Text colour commands, it's just as easy for me to do it all then.

I currently use the Notepad++ Replace All command to replace the < H1 > with { c } { red } { b } to get the presentation I want. Since I'm having to work that to get the colour in, there's no need for you to do extra work on it. - similar with the H2

Pedantic are we?

Hey, we're authors. We live by our words, and screwing them up causes readers to get lost. For us, words count!

The < font color="red" > is invalid html 4.01 and html 5, so can't support it without making the site tag soup. The {red}, {blue} {green} tags are the correct formatting for colorisation. I could support it by converting it to the site's tags. Haven't done it already because nobody asked for it specifically.

I'm not sure it's terribly essential, as I suspect Ernest is the only one who uses it.

@Ernest

I prefer to, and currently do, use basic HTML and avoid using a CSS, but if there is a way to use one to get what I want at SoL as well as in HTML, then I'll use it - anything to reduce the workload on everyone involved.

SOL isn't geared to use Styles, they simply use basic paragraphs, so the CSS isn't necessary. I suspect Lazeez was referring to his own, internal CSS tags.

I do this for two reasons, the main one being when Calibre creates the Contents list for the e-pub it uses the H1 and H2 headings to do so, and ignores the Heading used for the title.

I quit relying on the h1 tags when I started using graphic chapter headers. I still use it, but I list the entries to include in the tag itself. < h1 title="Text chapter title" >

For the book title, I simply use title="Title Page", so the index will take the reader to the first page without listing the name of the book. You could also use this technique to create Index entries without creating separate pages in the document (if you want to do that).

So, I'm open to suggestions in that regard too.

In the Format Guidelines you list HTML codes you accept as:

italic
bold
bold-italic
emphasize
strong
superscript
blockquote
horizontal rules
H3, H4 and H5 header tags

Will you consider allowing the use of HTML code for H1 and H2 header tags, the 'center' paragraph alignment tag, 'BR' command, and font colour tags to match the colours you provide for in the Tagged Text options (red, blue, green).

Structurally sound html files should have only one h1 tag and it's reserved for the title. The h2 tag is reserved for the author name and chapter title.

I already use the Tagged Text codes you mention in the other two paragraphs, so I won't discuss them. It's good to know why you don't allow the HTML code for the items I use and you don't allow. I already spend time to convert to the Tagged Text file for you, so I'll continue to do so. But I will experiment with Calibre to see if I can get it to work the way I want using deeper header codes to reduce the code conversion load.

I prefer to, and currently do, use basic HTML and avoid using a CSS, but if there is a way to use one to get what I want at SoL as well as in HTML, then I'll use it - anything to reduce the workload on everyone involved.

The following is for information purposes so you know what I do and why.

Now, as to the headers. I write in Libre Office and it has Heading which I use for the story title, and use H1 for a chapter heading and H2 for a sub-chapter heading . I do this for two reasons, the main one being when Calibre creates the Contents list for the e-pub it uses the H1 and H2 headings to do so, and ignores the Heading used for the title. This is good because I know if I have it in the file for a short story you strip it out, anyway, thus I tend to strip it out of the file while converting it.

Where I use the colour in the files for SoL is in H1 (red text), H2 (blue text), and BLOCKQUOTE (blue text) - Although I'm now using just coloured text for some of the situations I've used the BLOCKQUOTE in the past.

I'm open to suggestion of new useful features to support in html. Please don't ask for justified text. I have a thing against it and hate it with a passion as most HTML engine does it so poorly it looks terribly ugly, that's one of the reasons that I personally hate the Kindle and its format, you can't turn off forced justification.

In General I would say, streamline the SOL code a bit, with underlines,i-tags and {_ _} tags we have three diferrent ways of coding italic text, that's overkill really, pretty much proven by the fact that the format previewer cant render _underscore'd inline italic text_ properly. I'm currently sitting in the train, which is not the best environment to work, but I'll post a proposal for a overhauled (but backwards compatible) sol code tomorrow. ODF conversion should be no problem, Openoffice does that automagically for you and I'm working on the converter plugin right now, once that is done, I'm willing to make it available for all members of SOL.

Should be no problem for authors. But OpenOffice.org/LibreOffice doesn't fit in our workflow. So we can't support it.

You don't need to support it. That's what the plugin is for that I'm working on. You write your text as a normal ODF file and then you select "Convert to SOL" from the menu and it produces a properly formatted file with SOL codes and all unsupported formatting already stripped. The goal is that people don't have to markup files manually anymore and you get properly prepared files.

Once we've tested it, I'll probably do an Office variant too.

In essence, since people can do their formatting on their own, it should lessen your workload too.

Once we've tested it, I'll probably do an Office variant too.

As a confirmed WORD user, one of my issues is keeping a uniform look to my different files. In essence, I maintain the Styles in my html submission--which get stripped out--but when I include the { p } header, I end up added several commands since the { p } doesn't break to a new line while viewing the displayed results. Thus, you may want to strip out any initial commands immediately following the initial { p } label.

I'm interested in helping out. I'm on OpenOffice 4.1.2

Those who are interested in helping test this plugin, please let me know, including which version of OpenOffice/Libreoffice/NeoOffice you're using.

I'm interested i it, and I just sent you an email with some details on what format items I use. But I forgot to mention I'm using Libre Office version 5.1 and will be switching to 5.2 as soon as it comes out.

edit to add: In 5.0 or 5.1 they changed the Save icon button to be a Split Button with a drop-down box as well as the usual single action. I have problems using it on my screen, and started a Bugzilla thread on it. They acted on it, and in 5.2 they're putting in an option where you can activate the old style single action icon button instead of the Split Button. I want that, so I'll upgrade as soon as it comes out.

I'm interested i it, and I just sent you an email with some details on what format items I use. But I forgot to mention I'm using Libre Office version 5.1 and will be switching to 5.2 as soon as it comes out.

I've got to say, this option seems more popular than I'd assumed over the course of many discussions on the topic over the years. Someone will need to compare the coded output by both OO and LO to see how disparate they are. Another complication, releasing it first on either one is likely to intimate there's less support than there actually is, as I'm still assuming many authors use either M$ Office, other 'no-nonsense' writing tools or even worse, Google Docs!

@Bondi

I sat there comparing this kind of rambling wandering narrative to the clean precise simple (well, with a LaTeX or other front end, anyway) program he'd written.

That's why they pay us authors the big bucks! We're better with words than we are with code or numbers.

as I'm still assuming many authors use either M$ Office, other 'no-nonsense' writing tools or even worse, Google Docs!

Assuming is correct. In many European countries using Open Document Formats is the government standard and many use Open Office or Libre Office because they work the same on MS Windows as well as Linux and Unix. I'd think a lot of the authors over there will be using it too. The same applies to many countries outside of North America. However, since SoL and most of the author blogs etc are NA based, as a re a lot of companies like Amazon etc, it's easy to see a MS bias there.

I've got to say, this option seems more popular than I'd assumed over the course of many discussions on the topic over the years. Someone will need to compare the coded output by both OO and LO to see how disparate they are. Another complication, releasing it first on either one is likely to intimate there's less support than there actually is, as I'm still assuming many authors use either M$ Office, other 'no-nonsense' writing tools or even worse, Google Docs!

The plugin should work for Libreoffice, OpenOffice and NeoOffice right out of the box. The Internal script language was designed for OpenOffice 3.4 which was way before the fork of LibreOffice.

The plugin would have been ridiculously easy to write if it wasn't for the fact that { i } and { b } tags cannot span across paragraphs, which means it needs some extra handling that may require retroactive changes to already converted earlier paragraphs when encountering bold or italic texts that span several paragraphs.

The other thing is recognizing scene separators for the case that people use custom ones instead of *****

I'm one of those people...

The other thing is recognizing scene separators for the case that people use custom ones instead of *****

Isn't that what the horizontal rule is for??

Heck even if what the system did was just to incorporate the actual text or image the people put it, they'd be ahead.

as to multi-paragraph bold and italics and font colour, the current format code applies that stuff on a paragraph by paragraph basis. So why not just have the converter do that, but only recognise the ones SoL uses?

I'll leave it all up to you, since you know what you're doing with the coding. Just thought I'd toss a few thoughts in there in response to your comment.

Isn't that what the horizontal rule is for??

I use custom markers in my Star Trek Stories that are meant to resemble the early Starfleet Logo (see "I grieve with thee" for reference). I've developed a logic for that, but it's a bit more tricky to code.

As for the bolds and italics paragraphs, you've just given me an idea that'll save me a crap load of work.

I initially wanted to have an output like that

{_ first italic paragraph

sencond italic paragraph_}

Why not code it like that

{ i }First italic paragraph{ / i }

{ i }Second italic paragraph { / i }

Brilliant idea :) I owe you one.

{ i }First italic paragraph{ / i }

{ i }Second italic paragraph { / i }

I often do a section of multiple paragraphs that are block quoted. I used to use the SoL tagged text block but very recently switch to just having each paragraph set up as:

{ blue } { i } text text { / i } { / blue }

The only thing to really watch out for using this process with a paragraph and a header, is to make sure you close everything off in the right order at the end of the paragraph.

I do the same with the H1 and H2 and H3 headers all three a centered, H1 is bold red, H2 is bold blue italics, and H3 is plain bold so they end up with the relevant variants of below:

{ c } { blue } { i } { b } text text { / b } { / i } { / blue }

I've also found leaving a blank line between paragraphs and between the header line and the paragraph minimises problems of the code accidentally flowing into the next paragraph.

I've found doing it this way give me more flexibility and ensures each paragraph gets the right code without any accidental issues with the SoL wizard, which has been known to have the odd hiccup at times.

Skipping a bunch of detailed descriptions. Make a plane text copy and submit it to the posting wizard.

If you need a bunch of special effects to carry your story you need to work on your writing skill.

And you need an attitude adjustment it seems.Come back when you have to add more to the discussion than a mindless attack on fellow authors. Oh, and it's 'plain text copy'. You should feel ashamed of needing a German to explain your own language to you.

If you need a bunch of special effects to carry your story you need to work on your writing skill.

There's a hell of a difference between selling something and providing a good presentation and I'm sorry you don't seem to realise that.

Many a very good car had poor sales because it didn't look nice enough to sell well.

The thing I notice most in published books is the words. Pretty graphics and illustrations are a nice addition, as long as they aren't overdone and distracting from the story, but they're the publisher's purview, and have nothing to do with the story.

I agree. The story must always stand on it's own. But, moderate use of graphics, in the proper setting, can help set the mood of a story, or can relieve the continual 'wall of text' issue by giving the eyes a break occasionally (say with section breaks or chapter headers).

I find this insistence on 'nothing but ascii text characters' to be an overemphasis on simplicity (such as eliminating italics for thoughts, titles and telepathic communications). If formatting can help a story, I'm all for it. If it's a distraction, it can either be eliminated or ignored.

Make a plain text copy and submit it to the posting wizard.

A good writer uses all the tools available. Other than the obvious grammatical tools of quotes and punctuation text format is a very useful tool. Italics and bold to emphasis various things, and the use of indented text to show a reproduction of a written letter or message etc is a very old writing tool as well. Can't do all these in plain text documents, and thus lose the richness of the story, and sometimes the plot itself when people have to take time out from the story to work out why the change when a format change would have made it clear what was happening.

And never did I feel I needed that stuff to make it clear what was happening.

It's not strictly necessary. After all, authors have been writing for thousands of years, without any special formatting tools other than their fingers. But still, it's easier to parse that you're reading something else (a hand-written note, or a public address), when it's indented. It sets it apart, and alerts the reader that it's not a simple continuation of the story. The reader knows to pay attention, so they're likely to pick up the change in context.

The same is true for italics. I'm not a fan of bolding or color changes--too often it's a mark of a beginning writer's lack of confidence that they'll use a variety of conflicting formats. But ... sometimes an author wants to highlight a specific word to emphasize how a passage is spoken (especially in dialogue), and so the italics do help convey meaning.

The key is to avoid getting carried away. It's like adding emphasis. Having someone shout "GET DOWN!!!!!!!!!!!!!!!!" doesn't add any import to the story. "Get down!" is clear and concise. There's no need to add unnecessary complications.

That said, in a world of abundant FREE 5,000 word "novels", it's nice being able to justify a heftier $5.99 ebook price by adding higher production values.

It's like adding publishing marks, especially em-dashes and ellipses. You can simply include a simple dash, or three dots, but you can achieve much more with the printed text (like designating an interruption in speech) if you use the proper tools.

does anyone remember how many years it took to get the average computer user to STOP double-spacing after a period? And to not use the space bar to indent lists and tables?

It hasn't stopped yet. May when those doing it all die out.

when one confuses the requirements for screen display versus the luxury of printed page production.

I don't use all the format options available to me, but use a mix to differentiate the text for certain context usages to carry across in print and a number of screen uses so I don't have to do much work to get a good and easy to follow presentation in the main final products I use. I covered all this in earlier posts.

OTHERS amongst us turn loose the entire inventory of Microsoft Word machinery to achieve a miraculous representation of a 17th Century Trappist Monk's Hand-Lettered Illuminated Holy Psalm Book.

Sorry to disappoint you, but while I do some advanced things, I don't do them in WORD. I use WORD to:

1: use Style Definitions to ensure all my text is formatted consistently across every usage, and
2: to calculate page numbers, so I can create a text based table of contents.

All my other formatting "bells and whistles" are done elsewhere, like in html or image processors.

Yup. I am disappointed. LibreOffice, perhaps?

Nope. I've got no problem with LO or OO, but having worked for years in a variety of American businesses, I'm simply more familiar with WORD. But the point is, you can't blame over the top graphics on programs you don't like.

I use a proportional font in my on-screen drafting; it's easier to read. I like Gazette LT Std. It's a nice news font, designed for easy reading. I also like Courier Prime (an open-source font; giggle it to download) mono-space font, but its not as easy for my eyes to scan and read. TNR makes my teeth ache, but that's because I'm old and weird.

And that's your perrogative, as SOL, html and most ebooks support that. That's why authors don't insert font specifics (fonts, font sizes, etc.) into our documents. Instead, we also use proportional sizes. Double sized characters become "2em;" in html end epub, so whatever the size of your selected font, it doubles in size.

However, the 'double spaces' reference is really a non-starter. However the phrase originated, everyone knows what it means, regardless of when they learned computers. It's simply spacing paragraphs so there are two lines after each paragraph instead of one. Few of us actually hit the return key twice (technically, these were be two paragraphs marks, rather than two linefeeds, as linefeeds are frowned upon for ending paragraphs). Instead, we define our default paragraph style to put enough space after each paragraph to insert comments. That way, the actual paragraph spacing rests with the user/site it's displayed on.

And yes, lifefeeds are still used, but they're now restricted to cases where we want to continue the same paragraph on another line, such as in the use of poetry, where the spacing of the line is important.

However, the 'double spaces' reference is really a non-starter. However the phrase originated, everyone knows what it means, regardless of when they learned computers. It's simply spacing paragraphs so there are two lines after each paragraph instead of one.

CW,

I always had the understanding that double spacing in text went back to the early days of using typewriters were two character spacers were left between the full stop and the first letter of the next sentence to make the start of the sentence stand out more. This was achieved by hitting the space bar twice. There are some people who still do this with computer generated text documents. If you replace the space bar spaces after the full stop with an underscore line the difference you get is:

... the ship stopped.__The captain said ...

... the ship stopped._The captain said ...

With the old typewriters the small full stop was often missed, so the extra wide space made it stand out more.

typo edit

Double space do disappear in html though unless you enforce them with & nbsp;

I always had the understanding that double spacing in text went back to the early days of using typewriters were two character spacers were left between the full stop and the first letter of the next sentence to make the start of the sentence stand out more.

Nope. That's officially called "putting too many spaces after the period/full-stop". "Double spacing" is the technical term for adding extra spacing either between lines of text or paragraphs, so readers can make notes or to make it easier to read. "Double carriage returns" or more accurately "double paragraph marks", if you will.

Note: Usage may differ in lands down under.

For those of us with bad eyesight, high resolution monitors and some fonts make it difficult at times to distinguish a comma from a period so two spaces between sentences is still useful.

A better approach is to either increase the font size, or switch to a clearer font--say one which isn't proportional. But for publishing, which is what we all do, even if we just post here on SOL, you shouldn't force it on readers. That's why html was designed to ignore extra spaces.

I'm not saying it doesn't help, but it's not up to an author to decide what fonts and character spacing a reader uses. If you enforce extra spaces, you're just as likely to annoy younger readers.

I also double space (insert a blank line) between paragraphs. I prefer to do this with paragraph breaks as that forces the spacing, regardless of what the program does.

I take the opposite approach. By relying on Style Definitions, my source documents are double spaced, but the final documents are already formatted as single spaced. Thus I don't have to worry about how each document will look, as long as I correctly label them as I'm writing. (SOL postings don't count, as they only accept one type of paragraph in any case.)

SCREEN: keep it simple. Keep it universal. My 21" monitor & my 4" phablet need universal coding to display the same page of text. That's (X)HTML. SOL/FS has it down very nicely! Just enough bling & eye-candy to do what y'all are advocating here: italics, bold, blockquote, color,

Second that.

bb

I think I am missing something in this conversation.

The Slim Rhino is developing a plug-in to convert an LO .odt file direct into a SoL ready file - much the same way as the one click icon creates a PDF file from the master file for you. This saves you having to create the html file.

The Slim Rhino is developing a plug-in to convert an LO .odt file direct into a SoL ready file - much the same way as the one click icon creates a PDF file from the master file for you. This saves you having to create the html file.

The plug-in is supposed to avoid the bloatware that those programs (mostly M$) puts into their html files, as well as converting directly to SOL specific code (rather than html tags).