Forum: Bug Report and Feature Requests

Emoticons? Really? I assume you are past 16 so please leave the use of emoticons to the mentally retarded youth. Use an incidental ;) or :D but leave it that.

And if the story includes teens using smartphones to text, they'd be appropriate, so it's actually a question I'm going to have for AWLL at some point - how to include the necessary emoticons for a teen text convo using smartphones. :-)

Ok, you got me there. That would be appropriate usage of emoticons.

Actually, a better use of in-story emoticons would be to have the teenager discussing her texts aloud as she texts, so you're not displaying the actual moronic message, but how the teenagers typically describe their texts.

Ex:

Oh yeah, well wavy hands, eggplant, wavy hands to you to, Jason!

That way, rather than being illegible to many readers, you're instead relaying the private discussion as dialogue, with all it's natural literary nuance.

Excellent idea :)

I already have a scene for the next manor-house series where the parents cease Emily's phone and amusingly completely misinterpret some emoji texts- although I might need pictures to make sure they render properly if I can't get it to work as wavy eggplants stuff :)

So if you submit in html or UTF-8 encoded plain text, the emojis will be kept as is.

If I haven't told you how much I love your code, let me do so now! That makes it trivial for me, as I only work in UTF-8 encoded plain text! :-)

and maybe soon enough the ability to accept simple .docx

That would be great!

For something completely unrelated, I have Popen'ed libreoffice to convert odf/docx to pdf/html. The command line to use libreoffice is obscure. Let me know if you want the incantations.

Ah what lib are you using with docx and odf? Now I'm curious :)

Most of my command line stuff are to make libreoffice "headless" so I can run it on the server. It took some experimenting as libreoffice doesn't naturally not start ui, but it can be done.

Emojis? As long as the text you submit is properly encoded, emojis will survive and show up on the site. So if you submit in html or UTF-8 encoded plain text, the emojis will be kept as is.

Rethinking this (almost a month later), this doesn't always work, as each smartphone will depict the same emoticons differently, so what fits one teenager, will only look dated when relayed via M$ default emojis.

A more reliable way would be to not do a second-hand display, but to do a screen grab on a particular device, and then to attach that image to your story (though you're generally limited as to the number of images you can include per chapter on SOL).

I use Calibre to make the e-pubs, however before I get to that I use LO to make a html copy of the story from the odt copy then I run a script to remove all of the excess formatting code to have a clean html copy into which I place my own stylesheet code and I adjust the image code to suit my storage system.

Like a lot of things, I've found that Mac's are much better at cleaning html code than either PCs or Linux boxes. Unfortunately, once they strip out all the extraneous codes, they leave behind all the associated span commands (ex: < span>< /span>). :( But other than that, there isn't much left to clean up.

they leave behind all the associated span commands (ex: < span>< /span>).

From my research way back on converting a Word doc to XHTML by hand, there was a need for the span for centering. You needed two HTML commands (one being span) to ensure the centering worked on all devices.

< span>< /span> is an inline level tag. As in not paragraph level and you can't use it to centre a paragraph.

This is what I read was needed (both were needed):

p.centered
{
text-indent: 0em;
text-align: center;
}

span.centered
{
text-indent: 0em;
text-align: center;
}

< p >< p class="centered">< span class="centered">* * * *< /span>< /p>< /p>

According to normal html rules just < p class="centered" > ... < /p > should do it. Don't nest < p >'s.

It was from http://guidohenkel.com/2010/12/take-pride-in-your-ebook-formatting/

From Part VII:

Someone versed in HTML would probably go about and simply wrap these stars with < center > and < /center > tags. Sadly, that's a bad idea when it comes to eBooks.

Centering text in eBooks is one of the most error prone undertakings because device manufacturers seem to have different takes on what "centering" means. Sounds ridiculous, I know, but I am not lying to you.

To create foolproof centering we have to double-stitch our approach, to make sure every device understands exactly what it is we're trying to do.

[[ …he shows the two styles here… ]]

Since both declarations look identical, this might seem redundant, but sadly, some devices, like the iPad, require the < span > tag for centered elements, while others require the more commonly used < p > tag. I think it is also important to point out that the text-indent: 0em; setting is important in this context. Without it, the device would actually render our text slightly off-center because it would center the text and then add a 1.5em indentation to it. Not what we want, so we have to reset the indentation to zero.

To center our text line, we will now wrap it with the proper HTML tags and make it look like this.

< p class="centered" >< span class="centered" >***< /span >< /p >

This may not look nice in code form, but it solves all our problems and the line will now be centered correctly on all devices I have come across.

< span > inside < p > is OK, but not surrounding that again with a < p > like in your first post.

Oh. I don't know why I did that in my XHTML. But I just checked and it's that way on all the centered * * * * paragraphs. Probably because I copied the first one to the others when needed.

That was the first ebook I did. Someday I'll go back and reverse what I did (docx to XHTML) so that I have the Word docx file as my master. Then I'll run it through Calibre and republish the novel. I actually hate not having my master copy as a docx.

You are better of with using the .odt format.

I tried OpenOffice on my old PC and LibreOffice on my current Mac. Uninstalled them as soon as I tried them. I guess I'm too entrenched in Word. I'm one of those who love Word (and Excel).

It's having the master in XHTML that I hate. I'm always afraid I'm going to change something in the story that will accidentally affect the XHTML negatively and I'm not a techie. So I don't make changes.

I want to go back and add preview chapters at the end of this novel of the first novel of another series. I remember having a hell-of-a-time building the table of contents in XHTML and the new preview section would need to be in the table of contents. With docx, all I do is define the paragraph as Heading 1 and Calibre creates the table of contents. Plus I'd have to convert those preview chapters to XHTML.

My solution on my Mac is to use Scrivener to create my digital editions - ePub, mobi, docx, and pdf. I do all my writing in BBEdit in UTF-8 text with the SOL simple formatting tags for italics, bold, etc. Each chapter is a separate text file, making it simple to submit to SOL. I have a script which takes a group of one or more text files and converts them into markdown so I can properly import everything into Scrivener and get automatic formatting. I use Scrivener's defined document sections to get the centering, etc.

Fundamentally, at least in my experience, it's much better writing in plain text than worrying about what Word or Pages is going to do to what I consider my source files.

I agree, this is sane.

I think my next story will have emoticons in the WhatsItApp messages.

It's having the master in XHTML that I hate. I'm always afraid I'm going to change something in the story that will accidentally affect the XHTML negatively and I'm not a techie. So I don't make changes.

Since I work extensively in epub html code, including deconstructing the code to see precisely what's irrelevent, if you want to send me a sample of your code, I'll let you know whether I spot anything which might trip you up. Most things are allowed, though they'll ultimately limit the responsiveness of the resulting ebook.

Hint: Purging Styles is largely a waste for most authors, but limiting the Styles you use is more efficient (it means fewer to track and maintain).

, if you want to send me a sample of your code, I'll let you know whether I spot anything which might trip you up.

There's very little HTML code in the file. What I was referring to was accidentally deleting a < in front of the "i" when editing. Stuff like that.

But the biggest problem is I can't open the .html file with Word so editing is a nightmare.

It doesn't matter, though. I'm going to make the master for the novel docx again and run it through Calibre like all my other novels. The problem is the doc file I have doesn't have the changes I made to it after publishing it. So I'm going to have to read it through again. And when I do that, I end up making changes so it might end up as Version 2.

You might find a little program called Textedit useful...

I have TextEdit. I also have CotEditor to edit HTML. But they are not Word.

as TextEdit edits HTML

CotEditor is a good HTML editor.

This is what I read was needed (both were needed):

p.centered
{
text-indent: 0em;
text-align: center;
}

Technically, any null instructions, such as your "text-indent: 0em;", aren't needed, as each style definition is unique to itself (i.e. you don't need to invalidate each of the other possible styles used elsewhere in the document).
@Keet
That looks so terribly wrong. According to normal html rules just < p class="centered" > ... < /p > should do it. Don't nest < p >'s.

You're correct. I assume that Switch mistakenly duplicated the < p> tags, as only his '< p class="centered">' tag is necessary.

To centre stuff you use a < p> tag or < div> tag.

That applies to an internal html engine, like SOL's. What Switch and I are discussing are Apple's specific publishing restrictions, which apply to any site's conversion process, whenever they distribute to Apple sites. As such, it's a separate discussion, restricted to the few on-site publishers.

From my research way back on converting a Word doc to XHTML by hand, there was a need for the span for centering. You needed two HTML commands (one being span) to ensure the centering worked on all devices.

Yes, that IS true, but it only applies to anything displayed on Apple Books. What's more, it only applies to centered images, and not simple text strings, regardless of how you format them (though various 3rd-hand publishing sites, like Lulu, and continually harassed by Apple over this policy in order to scare authors away (i.e. they enforce rules they don't apply to themselves).

Since I only use images in certain locations (chapter header, section headers and section breaks (within chapters)), they're easy enough to handle on a case-by-case basis (ex: cutting and pasting the final html commands over the bare-bones SOL centered "* * *" command.

The main caveat to this, is that I replace the ENTIRE html < head> (and ALL it's myriad of various never-used styles) to a specific subset of styles actually used within the story at large (i.e. it replaces hundreds of lines of useless text with a dozen lines of applicable text in a one-time cut and paste operation).