Home « Forum « Editors/Reviewers Hangout

Forum: Editors/Reviewers Hangout

Italics in stories - Editing stories

Bartleby T

I'm not sure if this is the correct thread for this but here goes: Does anyone else use Gdocs to write and the "convert to html" feature to submit? I've just returned to the site after a very long time away, and I'm tossing up some of the stuff I've written, but all of my italics were lost in the conversion. I guess I could go through and tag them all like this but is there any way to make sure they come through without trying to find specific parts of my story in the giant wall of code that the "convert to html" feature creates?

Additionally, some of my readers have pointed out errors in my text that I'd like to fix. But will uploading fixes to my story change the stats? I don't want to erase all of my positive votes just to fix a few typos so I thought I'd make sure first.

Thanks.

Crumbly Writer

I've got a friend who insists on using Google Docs--despite the trouble Google has heaped on him over the years (yanking his accounts, deleting all his files, etc.), and I always cringe when I receive a Google Docs file from him, because it's SO difficult to do anything in Google Docs!

I'd suggest--if you insist on allowing Google to read every word you place in a story and sell it to whoever is interested--then I'd suggested you not italicize within Gdocs. Instead, use the "_text_" or "*text*" for bolding. That way, the coding will be transferred intact (as text) and SOL will properly display it.

And don't worry about posting corrections to SOL. That's the wonderful thing about posting online. Instead of submitting works to a publisher, where your words are frozen in time, you can make changes anytime someone suggests a change. It won't affect your scores or ratings at all, and it makes your writing appear better quality (typos always look amateurish).

Replies:   Bartleby T
Bartleby T

@Crumbly Writer

I guess that's what I'll have to do. It's just bizarre, though. Why wouldn't a "convert to html" tool convert (i) tags? I wish I could just upload an .rtf but I guess there's probably heaps of problems that stem from that.

Thanks for your help.

Ernest Bywater

@Bartleby T

When I saw the thread title I thought it was going to be a discussion on the different ways to use italics, but see it's actually about using Gdocs. Considering you can get full blown office suites packages for free (Libre Office being what I use) I wonder why you go through the troubles you have using Gdocs when it does things like that to you.

Have fun working it out, if you can.

Bartleby T

Wow. I had no idea people disliked Gdocs so much. On my home computer, I have Office 2012 Professional but I actually prefer Gdocs because it does away with a lot of useless bells and whistles. I also write in multiple locations so Drive is incredibly useful. But thanks anyway. Sorry about the confusion, I didn't know where else to ask a formatting question.

Switch Blayde
Updated:

@Bartleby T

I write in Word so I didn't reply since I don't have any Gdocs experience/knowledge. But when I'm writing a story for SOL, I do not use Word's ctl/i to make it italics. I actually put the HTML tags before and after it. Then when I submit the story to the Wizard it converts it to SOL's format.

But the more I write, the less italics I seem to be using so it's no big deal to do that.

Ernest Bywater

@Bartleby T

does away with a lot of useless bells and whistles. I also write in multiple locations


What I like about Libre Office is it is so easy to use, but has the extra capabilities if you want to use them. It's like the pre-ribbon MS Word. I also use a number of locations to do my writing, but I have copies of my latest master files on a USB drive I take everywhere I go and update the copies on my main system when I get back to it.

I've a problem with cloud storage because I've seen too many people lose all their data when something went wrong with the cloud storage people or the cloud storage people simply closed their doors. In short, I don't trust important data to a place I can't control the future of.

Crumbly Writer

@Bartleby T

Wow. I had no idea people disliked Gdocs so much. On my home computer, I have Office 2012 Professional but I actually prefer Gdocs because it does away with a lot of useless bells and whistles. I also write in multiple locations so Drive is incredibly useful. But thanks anyway. Sorry about the confusion, I didn't know where else to ask a formatting question.

This (the forum) is the correct place to ask these questions, but since it deals with writing, I'd put it in the "Author's Area", rather than the "Editing/Review" Area, since formatting has nothing to do with editing.

As for Google Docs, I'm mostly pissed at how Google, and Google Docs by extension, treats authors. In the case I referred to, a single user got upset about a story and registered a complaint. As a result of that single complaint, Google deleted the entire account, not allowing any protestation of innocence and the author lost months of work. After all, if the information is available from anywhere, why bother backing it up?

I'm also bothered about Google's selling your data. I've had enough trouble with Google marketing my comments to trust them on this. I got adds for rent-a-cars in cities I've never visited, simply because I researched story locations, and you can bet--if you mention medical conditions in a story--that Google will sell that information to medical companies.

In short, talking about Google online is like mentioning Amazon. Authors tend to have strong opinions about their livelihood, so while Amazon and Google offer new options, they also threaten much of what keeps booksellers afloat. Make of it what you will, but these companies also threaten much of what authors hold dear (like privacy and the ability to hold keep their information secure).

But separating Google from Google Docs, I understand the attraction of 'cloud computing', but Gdocs just has too many issues. While it doesn't have 'all the bells and whistles', there are also multiple areas where it just falls apart (as you've discovered). There other is their lack of "Review" features for editors to make corrections to an existing story. Sure, it's easy for them to access the story, but they can't make it up in any manner other than color coding the edits, which fails miserably when adding or removing commas.

@Switch

I do not use Word's ctl/i to make it italics. I actually put the HTML tags before and after it. Then when I submit the story to the Wizard it converts it to SOL's format.

That works when posting to SOL, but not when creating books for publication.

I prefer to format as I'm writing, rather than doing it all in a separate pass, simply because I prefer seeing what the reader sees. But either method works.

Replies:   Switch Blayde
Switch Blayde

@Crumbly Writer

That works when posting to SOL, but not when creating books for publication.


I believe he was addressing only SOL.

I prefer to format as I'm writing, rather than doing it all in a separate pass, simply because I prefer seeing what the reader sees


When I'm writing to publish, I do use italics and then use the global find/replace in Word to add the HTML tags.

Back to SOL, the reason I use the HTML tags instead of ctl/i is simply because I want to see what the reader sees. You see, I edit using my browser to display the story.

Lazeez Jiddan (Webmaster)
Updated:

@Bartleby T

I'm not sure if this is the correct thread for this but here goes: Does anyone else use Gdocs to write and the "convert to html" feature to submit? I've just returned to the site after a very long time away, and I'm tossing up some of the stuff I've written, but all of my italics were lost in the conversion. I guess I could go through and tag them all like this but is there any way to make sure they come through without trying to find specific parts of my story in the giant wall of code that the "convert to html" feature creates?


It's never been brought to my attention. I'll take a look at the html that they generate and see why we're not detecting bolding and italics.

Can't promise anything as some html generated is convoluted enough that only a browser engine could make sense of it.

Edit: In my (biased) opinion, the best way to write and post in various places is to use Markdown formatting.

Additionally, some of my readers have pointed out errors in my text that I'd like to fix. But will uploading fixes to my story change the stats? I don't want to erase all of my positive votes just to fix a few typos so I thought I'd make sure first.


Reposting doesn't affect stats.

Replies:   Ernest Bywater
Ernest Bywater

@Lazeez Jiddan (Webmaster)

Reposting doesn't affect stats.


Reposting a chapter or a story doesn't affect the stats, unless you delete the story first. Just use the Wizard option to repost the chapter or the story - I do ti all the time with no problems.

Ernest Bywater

@Bartleby T

italics were lost in the conversion.


Maybe you need to check what code Gdocs is using to tag it as italics with, because they may not be using normal html code. Some sites do ti with javascript and the like and that isn't html.

Ernest Bywater
Updated:

I think I found the problem here. I don't use Gdocs, so I went and had a look at it. When it saves as html it does not use basic or standard html code at all. It uses a style sheet and then marks the section of text with a span reference to use the relevant part of the stylesheet.

The SoL code instructions say:

http://storiesonline.net/doc/Text_Formatting_Information_Guide#htm

HTML files

If you feel like submitting your own html files you can do so. However, keep in mind that all html code gets stripped from your files with very specific exceptions, and your files get reformatted from scratch.

The exempted html codes carried over to the site are:

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

The site's conversion utilities try to support centered and right justified text, but it doesn't work very reliably due to the different ways this may be achieved.

Requirements:

HTML files must contain valid html code.
HTML file must be properly wrapped in tags.
HTML code must be complete with a section containing a character encoding declaration in a meta tag.
HTML code must contain a section.
Stylesheets are not preserved nor taken into account.
Only the above simple tags are respected and carried over to the final delivered text.

Improperly closed tags will result in formatting removal.

Failure to comply with the above requirement could result in unpredictable results. We may correct your html code or we may remove your formatting if fixing is too complicated or time consuming.

end quote

In the test I did in Gdocs I've replaced the angle brackets for the code with () brackets so the forum won't mistake it for code to do with it. Below is how Gdocs codes italics in a Gdoc work saved as html.

(span class="c1") I want this in italics(/span)

and this is how they do bold

(span class="c0")and this in bold(/span)

The problem is clearly with Gdocs not using standard html code for italics or bold. While you use Gdocs for this the italics and bold will never make the transfer.

Lazeez Jiddan (Webmaster)

@Ernest Bywater

@Bartleby T

italics were lost in the conversion.



Maybe you need to check what code Gdocs is using to tag it as italics with, because they may not be using normal html code. Some sites do ti with javascript and the like and that isn't html.


I took a look. It's convoluted and not easy to support. Their html generator creates a separate stylesheet for each style in the document.

If you use italics in your text, they use a < span class="cxx"> tag to wrap the italicized text with .cxx{font-style:italics} in the stylesheet and they don't use < i > tags. Then if you use bold, they create another class for bolding. If you use bold-italic, then they create a third class that is both bold and italics.

For me to support that, I would have to parse the text and the stylesheet and try to figure out which applies where and insert my tags at the correct places.

Complicated and I'm not sure that I would be able to detect all the instances because I saw a lot of unstyled < span > tags all over the document that I looked at.

Again, best thing to learn and use is Markdown. It's the other tagging/formatting system we support.

Replies:   Crumbly Writer
Crumbly Writer

@Lazeez Jiddan (Webmaster)

Again, best thing to learn and use is Markdown. It's the other tagging/formatting system we support.

Often, your best bet for creating html files is to create them using a simple text editor, even if you only cut and paste the text from another source. You can also do this with markdown, which Lazeez prefers. Relying on Gdocs is a mistake, as they have no experience with html tagging!

graybyrd

Text files with Markdown are insanely simple! Also most everything from a text editor up through apps like Scrivener and LibreOffice can produce Markdown text files. That makes it pretty universal. But like the TV hustle ... WAIT! You get not one, not two, but three for the price of one. A single Markdown text file can produce in turn, a PDF, an ODF, and an HTML file, containing all the formatting you've entered via Markdown. Slick! So my archives need contain only .md.txt files.

One Caveat! Be sure the editor of choice can produce UTF-8 coded text content! Most can, but be sure before posting an .md.txt file to SOL/FS.

Lazeez Jiddan (Webmaster)

@graybyrd

So my archives need contain only .md.txt files.


By the way, now we support the .mdown extension too.

Bartleby T

Wow. Thanks to all for the extremely well-researched answers to my question. I think I'm just going to have to go through and wrap my italics in underscores and my bolds in asterisks. I think I'll keep using gdocs just for the convenience but saving as plain text and putting in the tags manually isn't that much work. Thanks for the help.

Replies:   Crumbly Writer
Crumbly Writer

@Bartleby T

For posting, the issues with Gdocs isn't as apparent, but for publishing or posting to websites, most word processors utilize Styles, where each type of text is defined once as a specific style (like "H1" for Chapter titles, or "Indent" for indented text (as opposed to blockquotes).

Since gDocs doesn't support Style definitions, it renders it useless for posting to the internet or publishing purposes. You don't need to buy the M$ bait, but working with established formats makes publishing much easier.

As for your stories, Barleby, I'd rely on the old 'cut-and-paste' solution. Write all you want, but then convert the gDocs markup to standardized html (or SOL style markup) once you finish.

Replies:   graybyrd
graybyrd

@Crumbly Writer

for publishing or posting to websites, most word processors utilize Styles, where each type of text is defined once as a specific style (like "H1" for Chapter titles, or "Indent" for indented text (as opposed to blockquotes).


True, especially for generating a Word document for those sites or publishers that demand MS Word docs.

For those interested in the ASCII text simplicity (KISS) of Markdown and its various outputs, there are two excellent free apps for Windows.

MarkdownPad 2 translates to an HTML file. It features side-by-side panels so you see the result of the translation as you type in the text. See it at: markdownpad.com

WriteMonkey is a different approach: it features a full-screen distraction-free window, with a "right-click" pop-up menu system. It has more output choices, including copy to clipboard RTF output for pasting into Word, LibreOffice, etc. It will output HTML directly into your default web browser, or send RTF-formatted output into MS Word. It also features CSS style sheet templates.

See it at: http://writemonkey.com/index.php

There's an excellent recent review of what's available for Windows at: http://www.sitepoint.com/best-markdown-editors-windows/

Or for the ultimate in KISS solutions, use Notepad with a 'cheat sheet' from John Gruber's website. He started the Markdown movement.

Learn all about it: daringfireball.net

Replies:   Crumbly Writer
Crumbly Writer

@graybyrd

For those interested in the ASCII text simplicity (KISS) of Markdown and its various outputs, there are two excellent free apps for Windows.

My eternal frustration with the popularity (among developers) of 'markdown' writing apps, is that they generally don't support style guides. Thus, every time you indent a line, you only indent that one line, instead of defining "Indented text" once, and having that apply every time you utilize it. This is especially handy for centered/bolded text, section breaks, etc.

It doesn't matter much for SOL, but it becomes a major issue when publishing across a variety of platforms, each of which is implemented differently on different devices.

I'm intrigued that WriteMonkey supports CSS templates, but I'm skeptical it offers much in the way of features (i.e. you can justify all the text, but I doubt you can indent normal text but not indent the first paragraph of chapters/sections).

I keep looking at new writing tools, but so far, I've been intensely dissatisfied with the results. I'm especially frustrated because the few programs which did work well were bought out by larger corporations (M$ and Google, in two instances) and essentially trashed, only to be replaced with crap products.

By the way, I now build my own CSS instructions in my ePub documents, unfortunately, they require so much additional processing, I rarely publish them (since few publishing sites offer the functionality).

Replies:   graybyrd
graybyrd

@Crumbly Writer

My eternal frustration with the popularity (among developers) of 'markdown' writing apps, is that they generally don't support style guides.


My sympathies. However, and please don't take offense as none is intended ... but your message from start to finish tells me that you've misunderstood the entire rationale behind the Markdown philosophy and process.

I'll try to explain. Briefly, as an explanation of the premise, there are two major approaches to document preparation. For many years I was involved in the first school which was to prepare a document for printing. We followed a style guide that dictated all elements of the document appearance and we were required to follow that guide in detail. The printed page(s) were exactly as ordered. This was fine until someone wanted an alteration in the document appearance. The old was trashed, and we started all over again with the new. This was very expensive in time and labor.

Then new thinking arrived with digital technology: it is ridiculous to retype or typeset an entire document all over again just to accommodate style changes. So word processors and style sheets arrived. Just change the coding in the style sheet, and rerun the document.

Then the internet and websites and HTML came along, with a complete departure from the traditional printed page. This was an incredibly profound paradigm shift, and I'm convinced after all these years in and out of the industry, that many folks don't really understand what happened! With a wide range of computer monitor sizes and resolutions, it became virtually impossible for a conventional document to be displayed and read as it was intended to appear.

Look what happened when advertisers demanded that their on-screen product advertising and brochures appear on a web page exactly as they would on a magazine page!

Web designers went berserk, torturing HTML with table tricks and other non-standard gimmicks (blank pixel-size spacer graphics, anyone?). This eventually led to the creation of CSS, which was the screen display equivalent of style sheets in word processors. Text content was finally (again) separated from appearance.

NOW TO MY POINT (finally): we all generate plain text off the keyboard. Much time & effort is involved. We add coding to the text so the output will generate something more useful than a plain typewriter-like document. In Word, you add all that menu and stylesheet coding. For a web page, we add the HTML codes. And so on ...

But this often produces an output that is as limited as the printer's chase of lead type was back in the old days: to make all that typed output useful for another, different output, it needs to be converted, the old codes stripped and new ones inserted. That's wasteful and counter-productive.

Thus a very simplified coding system was developed to produce a generic product that could be used against a variety of filters to produce anything you want. It just depends on the filter used.

For most of us writers who want to output to a simple, universally-applicable web page that can be viewed on virtually any device, we use simple ASCII text with basic Markdown codes. We make no attempt at pretty-printing manipulation. None! Applied to a basic Markdown filter, the output will be basic HTML, or a PDF duplicating the appearance of that HTML output, or an RTF file also duplicating the appearance of that HTML product. We neither want nor expect any fancy-formatting beyond what the basic HTML product allows.

This is intentional. There is no attempt made to produce a hard-coded MS Word document containing all the magazine page formatting one might desire from a conventional Word document. The Markdown/HTML document is meant to be universal for display on any screen, of any resolution, ranging from your 25-inch monitor to your one-inch wristwatch. Try that with a Word document formatted to a firm page size!

A side benefit: the Markdown codes are dead simple to type, and do not slow down a touch typist. And the text remains extremely easy to read. The codes do NOT intrude on the readability of the text.

If you want a hard-coded magazine page, Markdown is NOT suitable for that process without additional processing. If you want a dead simple and blazing fast output for FS or SOL, use Markdown; and save the coded text to produce other products.

One last note: with different filters, and additional Markdown coded input, huge publishing houses like O'Reilly are able to take universal text input and generate an entire 900-page book with all elements of the book output correctly. Then with a different filter template, that very same Markdown (actually, MultiMarkdown) file is used to produce a totally different format containing the same text.

A web page is NOT a printed sheet; it must remain flexible for display in a multitude of sizes and resolutions. A hard-coded page is inflexible. If it fits a 6 x 9-inch book, it's impractical to use for a 5-1/2 x 8-inch or 5 x 7-1/2-inch book without serious reworking.

Think of HTML vs PDF: one is flexible, the other not. Each serves a purpose. Markdown is just a tool to produce the first, and limited formatting of the other. KISS.

-=GB=-

Replies:   Crumbly Writer
Crumbly Writer

@graybyrd

I understand the philosophy behind Markdown, but I'd rather not have to individually code each and every instance of a starting paragraph or an indentation (especially since Amazon limits the functionality of < blockquote > commands.

Although you don't force print formatting on a cellphone, that doesn't mean you can't ease the process. Markdown essentially assumes that authors are too stupid/insipid, to properly format things.

By using CSS Styles, I can display formatting (including graphic chapter headers) on a smartphone with no loss in readability or quality (I use a "width="80%"" setting to ensure the images are properly adjusted to fit the display and indent text as "2em;" (two character widths, whatever size the user selects for the character size on their display).

Ernest and I differ in that he wants each page of a document to display perfects, to the point he'll edit each page to ensure it breaks at the right point (no orphaned paragraphs spilling over to the next page). That's why Ernest only publishes .pdf ebooks. They're essentially copies of his print books. But that's not what I'm doing.

But there's no sense arguing formatting with someone focused on plain text markdown. You wouldn't use markdown if you wanted to format your documents.

My issue with Markdown is that those programs/apps are specifically designed for those terrified of technology. Those of us comfortable already known how to code reflexive (?) displays.

Also, this is NOT the place for arguments over markdown over CSS. No one cares, and it's too easy to get into petty, unimportant arguments.

Replies:   graybyrd
graybyrd

@Crumbly Writer

But there's no sense arguing formatting with someone focused on plain text markdown. You wouldn't use markdown if you wanted to format your documents.

My issue with Markdown is that those programs/apps are specifically designed for those terrified of technology. Those of us comfortable already known how to code reflexive (?) displays.

Also, this is NOT the place for arguments over markdown over CSS. No one cares, and it's too easy to get into petty, unimportant arguments.


Stick with what makes you happy. But this IS the place for a discussion (not an argument); and I would drop it if you weren't making such bald-faced WRONG statements about Markdown. Many thousands of people use it daily (check the forums) and it works.

Terrified of technology? You've just shot yourself in the foot with that grade-school comeback.

Let it rest, but please stop misleading people about a valuable tool.

Replies:   Crumbly Writer
Crumbly Writer

@graybyrd

But this IS the place for a discussion (not an argument); and I would drop it if you weren't making such bald-faced WRONG statements about Markdown. Many thousands of people use it daily (check the forums) and it works.

I'm not arguing that the "stripped down" writing apps aren't popular, my point was that there aren't any alternatives, and the few decent alternatives which existed were purchased by larger companies and removed so the Markdown apps wouldn't have any competition.

Just because stories are displayed on a small device doesn't mean you can't format documents. You just have to know what you're doing. With the Markdown programs, you've got to remember to format each individual instance, and even then, with CSS definitions, the formatting will often be overridden by select devices.

My text does not overflow the page, or force a specific font size/color on users, instead I use the appropriate ePub commands, which also apply to most other ebook formats as well.

It was just sounding like the discussion was descending into a "he said"/"he said" argument, with conflicting statements which most readers wouldn't be able to make sense of.

Anyway, there's enough of that. Some of us like formatting, some don't. Plain text is fine, but because I've included foreign languages in my earliest stories, I've long had to work around the limitations of ebook design. I'm used to it.

Back to Top