Paragraph indent problem

[Quoth]

Originally Posted by davidfor

Absolutely NOT the case. In fact, absolutely impossible.

Eh?
I used to have to power off or reset, or layout would be crazy or unchanged after updating by deleting & re-adding a book with CSS changed in Calibre. Now I don't have the problem.
The problem definitely existed. I don't know if changes to Calibre or the 4.8 FW update fixed it.

I'm not sure which aspect is impossible?

[davidfor]

Originally Posted by FrustratedReader

The issue of CSS not updated on book removal and replace has gone. No need to reset/power off. Perhaps that was a driver setting in Calibre.

Originally Posted by FrustratedReader

Eh?
I used to have to power off or reset, or layout would be crazy or unchanged after updating by deleting & re-adding a book with CSS changed in Calibre. Now I don't have the problem.
The problem definitely existed. I don't know if changes to Calibre or the 4.8 FW update fixed it.

I'm not sure which aspect is impossible?

I requoted what I was responding to. You are suggesting that a change in the KoboTouch driver setting is why you had to restart the device to get updated CSS. My response was that statement. I will state it again, maybe more clearly:

There is absolutely no way that the a change in the KoboTouch driver configuration would affect how the device handles the CSS.

I will also state, that there is nothing in the driver or calibre that would affect how the Kobo devices handle the CSS. The books are put onto the device for the device to handle. The device opens the books reads the text and CSS and uses/displays them. And as I have stated at least once in this thread, I have never seen the issue you are talking about. And to verify, I have just tried it: Opened an epub on the device and then connected to calibre. Found the epub in my calibre library and edit it. Add a class for "p" and set the text-indent to 24px. Found another class used by paragraphs and set the text-indent to 48px. Then sent the book to the device. Reponed the book on the device and the paragraphs now had indents. With some twice what the others were. So connected the device again, changed the styles so that the text-indents were 64px and 12px respectively. Sent the book again, opened it and, guess what, the new CSS was being used.

This has always been my experience. I fiddle with my books far to often to not have seen something like this happen. I do of course occasionally look at the book on the device and the changes I planned are not there. But, they have ALWAYS been because I made a mistake in the code or simply forgot to press the save button before sending the book.

And all this is why I have asked several times for you to post examples of what you are doing or at least screenshots/photos. Something is different for you and I have no idea what it is. You have described what you are doing but if I can't reproduce this, then one of us is doing something differently. You posting the code you are using will put us at the same starting point. And the chances of someone else being able to reproduce the problem will be increased. And then the chances of it being fixed will go up dramatically.

[Quoth]

Originally Posted by davidfor

You are suggesting that a change in the KoboTouch driver setting is why you had to restart the device to get updated CSS. My response was that statement. I will state it again, maybe more clearly:

There is absolutely no way that the a change in the KoboTouch driver configuration would affect how the device handles the CSS.

I wasn't suggesting it's the driver or Calibre. Or I'd have posted in the Calibre section.
The issue does seem to be purely how my Kobo H2O original interprets indent in point size or inches (any absolute measurement). The display is correct with "em" equivalent. It doesn't happen on my two other ePub readers or my ePub apps.
It's a Kobo CSS issue. Not the driver or Calibre, though if Calibre converted all point sizes in margins and indents to "ems" at 1em = 12pt it would never be noticed.
LibreOffice Writer version I have only supports absolute units, not the more HTML friendly "em".
The workaround seems to be to use the "remove spacing between paragraphs" and set to 1.4em (=16pt).
It's not the only mysterious bug of my Kobo. Sometimes during annotating a book it gets so slow for annotation that a reset is needed.

[Quoth]

Found what was messing up the paragraph indent ONLY on Kobo. Fine on other devices or apps. Summary of problem:
If the start of paragraph indent isn't in "em" then the size of if is half the expected on the Kobo H2O original on ePubs sent from Calibre. 1em = 12pt, to get 16pt the indent had to be 1.4em via "remove blank paragraphs and set indent", or manual edit of CSS. Setting it to 32pt gave correct view on Kobo, but then twice what it should be on anything else.
It may have been only the setting to use a file kobo_extra.css, which doesn't exist on my Kobo. See below.

On Device (when Kobo H2O original connected) I made two changes:
1) On "Extended" I unchecked "Enable Kobo Extended Features" presuming that this is what is silently converting ePubs to keypubs on the fly.
2) On "Collections, covers & uploads" I unchecked "Modify CSS", as why would I do this? The CSS works fine on three non-Kobo ePub readers and two ePub apps on phone & tablet. Hovering the mouse suggests this uses some file I think I don't have.
Now the ePubs are ePubs on the Kobo AND they NOW look the same as on all my other ways of reading ePubs! Not only that but unchecking "remove blank paragraphs" "Indent 1.4em" and thus leaving indent at 16pt now works on Kobo (before it was always 1/2 the point size set unless changed to em equivalent.

I don't want silently created kepubs. I want to see what ePubs look like, so I can proof what Smashwords might produce and see what other ePub users (Sony, Nook, Android & iOS apps etc) will see. I picked ePub2 in Calibre. That's what was going to my apps and other non-Kobo eReaders. It's not obvious:
Under Device (when Kobo connected):

On "Extended" tab there is "Enable Kobo Extended Features". It's not clear that if this is checked that you silently get kepubs and not epubs. I've checked in Book Details, and removal of book from device and resending after unchecking and Calibre restart the "Details" changes from Kobo Epub to Epub.
Now I have hundreds of books to fix
On books that have indent & no regular blank paragraphs: Delete all conversions, uncheck Calibre "remove blank paragraph" "Set indent" 1.4em and allow original indent usually in tenths of inches or points. Reload ALL my apps and eReaaders.
On ALL books on Kobo, remove and reload to remove kepubs. I'm not interested in Kobo's propriety extension. Mobi for old Kindles, AZW for newer Kindles and ePub2 for all apps and non-kindle eReaders.

[davidfor]

Originally Posted by FrustratedReader

Found what was messing up the paragraph indent ONLY on Kobo. Fine on other devices or apps. Summary of problem:
If the start of paragraph indent isn't in "em" then the size of if is half the expected on the Kobo H2O original on ePubs sent from Calibre. 1em = 12pt, to get 16pt the indent had to be 1.4em via "remove blank paragraphs and set indent", or manual edit of CSS. Setting it to 32pt gave correct view on Kobo, but then twice what it should be on anything else.
It may have been only the setting to use a file kobo_extra.css, which doesn't exist on my Kobo. See below.

On Device (when Kobo H2O original connected) I made two changes:
1) On "Extended" I unchecked "Enable Kobo Extended Features" presuming that this is what is silently converting ePubs to keypubs on the fly.

Yes, that is what that option is. The other "Extended" options are related. But, if you don't want kepubs, why did you install the extended driver? "Silently" transforming epubs to kepubs during the send is it's reason for existence.

2) On "Collections, covers & uploads" I unchecked "Modify CSS", as why would I do this? The CSS works fine on three non-Kobo ePub readers and two ePub apps on phone & tablet.

Because no two ereaders or apps from different manufacturer/developers interpret the epub standards in exactly the same way and this allows people to tweak things. It also allows people who share a library to tweak what they see. Or tweak the results for different Kobo devices. And because people wanted an easy way to strip the @page out of the CSS.

Hovering the mouse suggests this uses some file I think I don't have.

This option is off by default. If it is on, you turned it on. Maybe you do have the files it uses. But, if the "kobo_extra.css" file doesn't exist, it doesn't do anything.

[Quoth]

Originally Posted by davidfor

Yes, that is what that option is. The other "Extended" options are related. But, if you don't want kepubs, why did you install the extended driver? "Silently" transforming epubs to kepubs during the send is it's reason for existence.

That's not clear anywhere. It seemed like a driver for later Kobos like Aura HD and Kobo H2O.

Originally Posted by davidfor

Because no two ereaders or apps from different manufacturer/developers interpret the epub standards in exactly the same way and this allows people to tweak things. It also allows people who share a library to tweak what they see. Or tweak the results for different Kobo devices. And because people wanted an easy way to strip the @page out of the CSS.
This option is off by default. If it is on, you turned it on. Maybe you do have the files it uses. But, if the "kobo_extra.css" file doesn't exist, it doesn't do anything.

I definitely do not have "kobo_extra.css"
At any rate with these two options off, the Kobo layout now matches the screen in LibreOffice Writer when I create a copy of the source with small page size, 5pt margins, no headers and no footers and page numbers / ... removed from Contents by edit. Also matches Aldiko, Bluefire, (Android tablet & phone) Calibre eReader app, Binatone Readme Daily (Only in Adobe folder. Has LCD screen!). Nook Simple Touch and Sony PRS350. Also PW3 and later Basic Kindle when AZW and recent FW is used.
I used Calibre on Windows XP for a couple of years with three models of Kindle (Paperwhite, Basic touch & DXG) as well as apps on various Android things. Then I got the Kobo original H2O hoping at about 266 DPI and 6.8" screen it would be better for PDFs than the DXG (it's maybe slightly better, but still rubbish for magazine, Letter or A4 PDFs). At first it did as I expected with formatting.
Then the bug on paragraph indent appeared. By then I was using Calibre on Linux. I'd assumed it was a Firmware update that caused it. I'd not changed anything in Calibre for ages till the problem appeared. The only solution I'd found was to use "ems". Both Inches and Points came out haif as wide on the Kobo H2O compared to anything else.
Perhaps at some stage the Kobo Driver was updated. Or I changed the CSS setting, or I'd changed from one Kobo driver to another.
However if the settings in the driver are clearly labelled, both with clearer on dialogue text and the mouse hover text I'd have been spared a lot of wasted time and grief.
I've not tested to see which of the two settings I unchecked has fixed it. Obviously for what I want (Seeing format of same actual eBook on different devices as it would be from Amazon & Smashwords) both settings need unchecked.
If I'm wanting to waste time I may experiment to see if either setting "on" on its own causes the indent to be half width.
I'd never have imagined the eBook edit / CSS feature on the Calibre ePub v2 conversion from odt file or mobi file was showing DIFFERENT css/epub to what was being sent to the Kobo! A Driver should only transfer the file and update eReader database metadata and/or covers if needed. It should NEVER do a file content conversion or edit CSS. I'd never have suspected such a thing.

[Quoth]

I think I joined this forum back in June 2017 because I was annoyed with losing the old home screen that Calibre / Kobo GUI let me have ONLY a most recently used list of books / sketches (MRU).
Then this paragraph indent bug appeared sometime later and after being unable to solve it I posted in May 2018.
At the least to recreate: Have a Paragraph indent in LibreOffice Writer ODT of 16pt. Have the Modify CSS and Extended Features checked on.
See that in Calibre eReader app the indent is same as source document, but half on Kobo.
Then delete ePub on Device & Calibre. Use Calibre to make the 16pt indent be 1.4em either by edit CSS or the remove blank paragraph GUI. Kobo will then be correct.
Delete epubs again on device & Calibre, convert without changing indent/paragraphs. Uncheck Modify CSS and Extended Features options and send.

I suggest
1) Rename "Modify CSS" -> "Use kobo_extra.css" Double check nothing happens if it's missing.
2) Rename "Enable Kobo Extended Features" -> "Transfer ePub as Kepub" or some such and explain in Mouse hover that kepubs allow extra reading controls on (some?) models. I've still not understood why people want to change perfectly functional ePubs to kepubs, but that's fine, just make it clearer it's what this option does and why.
Most people using Calibre may never search MobileRead.

[davidfor]

Originally Posted by FrustratedReader

That's not clear anywhere. It seemed like a driver for later Kobos like Aura HD and Kobo H2O.

I have no idea where you got that idea. Reading the first post of the thread for the KoboTouchExtended driver will tell you what it does. Posting, "Do I need this?", like a lot of people have, would have told you.

I definitely do not have "kobo_extra.css"

In that case, I don't know why you turned the option on.

At any rate with these two options off, the Kobo layout now matches the screen in LibreOffice Writer when I create a copy of the source with small page size, 5pt margins, no headers and no footers and page numbers / ... removed from Contents by edit. Also matches Aldiko, Bluefire, (Android tablet & phone) Calibre eReader app, Binatone Readme Daily (Only in Adobe folder. Has LCD screen!). Nook Simple Touch and Sony PRS350. Also PW3 and later Basic Kindle when AZW and recent FW is used.
I used Calibre on Windows XP for a couple of years with three models of Kindle (Paperwhite, Basic touch & DXG) as well as apps on various Android things. Then I got the Kobo original H2O hoping at about 266 DPI and 6.8" screen it would be better for PDFs than the DXG (it's maybe slightly better, but still rubbish for magazine, Letter or A4 PDFs). At first it did as I expected with formatting.
Then the bug on paragraph indent appeared. By then I was using Calibre on Linux. I'd assumed it was a Firmware update that caused it. I'd not changed anything in Calibre for ages till the problem appeared. The only solution I'd found was to use "ems". Both Inches and Points came out haif as wide on the Kobo H2O compared to anything else.

And my understanding is that using non-absolute measurements is generally recommended for epubs. And those hard-coded 5pt margins? One of the reasons for the "Modify CSS" option.

Perhaps at some stage the Kobo Driver was updated. Or I changed the CSS setting, or I'd changed from one Kobo driver to another.

None of the default options in the KoboTouch or KoboTouchExtended drivers have changed. And the options you are talking about have been in the drivers a long time. Both the driver and the Modify CSS function were around a long time before the Aura H2O was released. The extended driver option defaults to on (pointless otherwise), the Modify CSS defaults to off. That has never changed.

However if the settings in the driver are clearly labelled, both with clearer on dialogue text and the mouse hover text I'd have been spared a lot of wasted time and grief.

Well the "Modify CSS" option is clearly labelled as you demonstrated above. The option in the extended driver possibly isn't. But, it is when you understand the purpose of the driver.

I've not tested to see which of the two settings I unchecked has fixed it. Obviously for what I want (Seeing format of same actual eBook on different devices as it would be from Amazon & Smashwords) both settings need unchecked.
If I'm wanting to waste time I may experiment to see if either setting "on" on its own causes the indent to be half width.
I'd never have imagined the eBook edit / CSS feature on the Calibre ePub v2 conversion from odt file or mobi file was showing DIFFERENT css/epub to what was being sent to the Kobo! A Driver should only transfer the file and update eReader database metadata and/or covers if needed. It should NEVER do a file content conversion or edit CSS. I'd never have suspected such a thing.

The job of the driver is to get the books on the device ready to be read. That means the books might need to be manipulated in different ways depending on the device. Or, the features people want to use. And these two functions have been explicitly written to make these changes. And are well documented. Both functions were the result of many requests from people here. Many, many requests.

And of course, the send-to-device process will do a conversion if there is no suitable format for the device. That is specified in the driver. So, the extended driver or the Modify CSS function is just an extension of this.

[davidfor]

Originally Posted by FrustratedReader

I suggest
1) Rename "Modify CSS" -> "Use kobo_extra.css"

Sorry, you want the option changed to something less clear? Even though you have demonstrated that you understand what the option does? And, the option is documented clearly.

Double check nothing happens if it's missing.

Based on the number of reports of problems with this function, it is working as intended. If you think there is a problem, please post exactly how I can reproduce the problem.

2) Rename "Enable Kobo Extended Features" -> "Transfer ePub as Kepub" or some such and explain in Mouse hover that kepubs allow extra reading controls on (some?) models.

If you want that changed, please post the request in the thread for the extended driver.

I've still not understood why people want to change perfectly functional ePubs to kepubs, but that's fine, just make it clearer it's what this option does and why.

As you complained about double-tapping an image to zoom in on it not always working, I find that a strange statement.

Most people using Calibre may never search MobileRead.

And it is a well know fact that people don't read manuals, look at tooltips or even really consider what they are doing. So, what's your point?

[Quoth]

"And my understanding is that using non-absolute measurements is generally recommended for epubs"
And HTML, because really mobi, epub etc are based on HTML.
Except NO source creation tool for writing allows ems, only absolute. Most eBooks seem to use points or tenths of an Inch.
Calibre conversion has no option simply to convert points or tenths (1em = 12pt is a standard), only the remove blank paragraphs and clobber to a particular em setting.

I'm approaching the issue from a familiarity with content creation, conversion and reading. You are defensively coming from the position of already understanding the driver, which certainly has unexpected functionality and is a great piece of work. Also from using Mobile Read, which I found by accident.

I've been writing software for over 30 years. In general programmers and managers do not see the user point of view in the design of the GUI. This is getting worse. Win8 was bad for desktop. Win10 is dreadful. Android is STILL like Windows 2.0 on high resolution. What is it with Monochrome and Flat? Yes eInk is monochrome. I've designed better GUI appearance on 1 bit monochrome LCDs, the eInk is much higher resolution and does some grey shades.

I'm maybe not a good communicator. I've had a problem for over 7 months with formatting on the Kobo, my own documents, ones from Amazon I've bought, mobi downloads from Gutenberg (I found the epub poorer on margins)

The 5pt vs 25pt vs different inner & outer margins of "odt" has NO effect at all on Amazon or Smashwords .doc upload or Calibre ODT to mobi/AZW/epub. I pointed out that I was using that simply to preview appearance in LibreOffice Writer.

My issue was real. I turned off two badly labelled options to solve it nearly 7 months later. The issue appeared originally without me changing any settings, either with a Kobo or Calibre/Plugin update.

I've suggested now how to replicate it. It's obviously a real bug either in Kobo FW, Calibre or Driver, or interaction between two of them.
I'm actually famous for reading manuals and tooltips. I found Mobile Read by accident, WHICH IS NOT A MANUAL. It's crazy that it's taken over seven months to get back to where I was when I first got the Kobo.
I was always able to enlarge images, though it took a few attempts. The double tap sometimes works and sometimes doesn't. If that's only kepubs, then I don't care. I will see can I enlarge them as before. It took a while for the Kobo to import over 1000 epubs!
I've now lost the reading position in them all, but at least I'm now looking the same format and file as on all the other epub readers.

I didn't even know there is a thread on "extended driver".

Obviously I'm a poor communicator, David, as you seem to have misunderstood almost everything I've said.

[DNSB]

Originally Posted by FrustratedReader

"And my understanding is that using non-absolute measurements is generally recommended for epubs"
And HTML, because really mobi, epub etc are based on HTML.
Except NO source creation tool for writing allows ems, only absolute. Most eBooks seem to use points or tenths of an Inch.
Calibre conversion has no option simply to convert points or tenths (1em = 12pt is a standard), only the remove blank paragraphs and clobber to a particular em setting.

No ebook source code creation tools(*) allow ems or other relative measurements? I am not aware of any epub editing tool that forces use of absolute measurements so perhaps you could name a few. You might tell the original creator of Sigil that it does not support relative measurements since it has allowed use of ems since the first time I tried it. Ditto for AWP, InDesign, Vellum and Jutoh though I would not recommend InDesign for most uses unless you absolutely need a feature that is not available elsewhere.

*: I specified ebook creation tool deliberately. Why use Word or LibreOffice or other general purpose tool when there are tools designed for that purpose?

Very few ebooks that I have seen use absolute measurements other than in the mobi specific sections. Any ebooks I've edited that use absolute measurements are converted to relative measurements by a collection of saved searchs. And yes, using absolute measurements even on web pages is generally held to be a "Bad Idea" unless you know what screen resolution the display device has.

Originally Posted by FrustratedReader

My issue was real. I turned off two badly labelled options to solve it nearly 7 months later. The issue appeared originally without me changing any settings, either with a Kobo or Calibre/Plugin update.

Sorry to disagree but I took the time to look at the KoboTouch and KoboTouchExtended driver before deciding which one to use. As davidfor has said, other than the on-the-fly conversion to kepub, there is little difference between them. It would appear that you installed the KoboTouchExtended driver without knowing what made it the "extended" driver and you never went through the driver options just to see what was available.

Originally Posted by FrustratedReader

I've suggested now how to replicate it. It's obviously a real bug either in Kobo FW, Calibre or Driver, or interaction between two of them.

Again, I have to disagree with you. I have no major issues with either the Kobo firmware or calibre or calibre's drivers and other plugins that I use. Something that does not work the way you expect is not a bug (IMNSHO).

Originally Posted by FrustratedReader

I'm actually famous for reading manuals and tooltips. I found Mobile Read by accident, WHICH IS NOT A MANUAL. It's crazy that it's taken over seven months to get back to where I was when I first got the Kobo.
I was always able to enlarge images, though it took a few attempts. The double tap sometimes works and sometimes doesn't. If that's only kepubs, then I don't care. I will see can I enlarge them as before. It took a while for the Kobo to import over 1000 epubs!
I've now lost the reading position in them all, but at least I'm now looking the same format and file as on all the other epub readers.

Sorry but I am surprised that you never Googled something like "zooming images on Kobo ereader". The first hits on that search all mention kepub. And oddly, several of them are links back to MobileRead.

Originally Posted by FrustratedReader

I didn't even know there is a thread on "extended driver".

Again, Google is your friend. The first hit I got on "kobotouchextended driver" was to the Calibre Plugins forum for that driver.

Originally Posted by FrustratedReader

Obviously I'm a poor communicator, David, as you seem to have misunderstood almost everything I've said.

From my point of view, it would appear more that you were overly sure of what issues you were seeing and possible causes. Then where you appeared to have trouble accepting comments such as zooming images only works for kepubs, it only added to the communication issues.

I may not be seeing the issues you are since I make a habit of checking any ebooks for errors after importing to calibre, cleaning up those errors and cleaning up the css (or adding a stylesheet if needed -- RemoveInlineStyles is a handy plugin for Sigil). After a few years of practice, it takes <5 minutes for a relatively clean input file. The final product is a rather boring layout according to several friends but then the content is the point.

[davidfor]

@FrustratedReader: DNSB answered most of my issues. But...

Personally, I don't think I was getting defensive. Or at least not very. But, you definitely were. You decided to install software without actually looking at what it did. You made assumptions about it that I cannot work out the basis for. And the fact that you have been a developer for over 30 years makes that almost a criminal act. Now, when I called you one this, you are attacking the developers of that software saying it is their fault. And, as I am one of those developers, I take that personally. Your lack of knowledge of MR is not a good excuse. As DNSB said, just about any search of these things will lead you hear. And the calibre help page explicitly points to MR as the place to "ask any question".

And just to be clear, the reason I rejected the change for the "Modify CSS" option is because it isn't better. The option as is, describes what is to be done (modify the CSS in a book when it is being uploaded). The tooltip gives some basic details of how this is done. If that is not enough, then you need to find help for this function. And searching the web would lead you here. Your suggestion doesn't give a clue as to what is being done. I will look revisit the options under my control. At the time that most of these were created, the configuration dialog was clumsy and hard to change. I rewrote that a while ago, but didn't change many of the option names or tooltips.

And also to be clear, as another developer with over 30 years experience, I am completely aware of developers blindness with respect to these things. I beg for people to tell me what is wrong with the documentation, the options, my posts or anything else. But, it is rare that someone says anything.

The other issue with all this is that you didn't do anything to help debug this problem. You reported a problem and gave some details of how you thought it it could be reproduced. But, that didn't work for anyone else. I remember trying and couldn't reproduce it. When you were asked a screenshot or a test file, you didn't produce anything. If you had posted a screenshot, about 30 seconds later, someone would have told you what the problem was. Or at least asked a question that would have lead to it. If you had posted a test file, or even code snippets, it would have taken 30 minutes for the same result.

[Quoth]

A screen shot would have told nothing more except I wasn't making it up.

The only sensible "content creation" tool to write is a wordprocessor. The output has to be PDF for POD and ms .doc or .docx to upload to Amazon. Only Google Books requires ePub upload for Google Play, though they seem to prefer PDF, which is stupid. Paper requires absolute measurements. Amazon & Smashwords when creating from the MS Word file leave the formatting much as it is. So it's important when "proofing" PDF and eBook that in both cases something sensible is happening. Also I do proof reading / edit notes on the Kobo. My Beta readers all use Kindles, either old ones (Mobi) or newer ones (AZW, publisher fonts supported). The text body is designed such that any common serif font ought to be OK, that there is no extra space between body text paragraphs as they use a first line indent. Headings, dividers, subheadings, Preambles, captions quotations etc may use different rules and before and/or after paragraph spacing. The only important aspect with them is Centre, Left, Right or Full justification (works on old kindles with Mobi if done correctly) and that the font size might be different (mostly OK). The non-body paragraph spacing is different for Paper and eBook. I save As with _eb.odt for eBook after Paper version is edited and only edit the Paper version. It's a quick job to change the Contents to have no page numbers, delete Header & Footer and edit paragraph styles to suit eBook (more restricted spacing at start of chapters).
Years ago before I had Calibre I used MobiCreator on windows to make .mobi ebooks. I'd edit in MS Word 2002, import to OpenOffice Writer and save as HTML (because the Mobicreator .doc import does this anyway and MS HTML export is ghastly), open the HTML in an HTML WYSISWYG editor like Webexpress, make any small changes. Do global ones in Notepad++ using regex. Import to Mobicreator.
I gave up Windows & MS Word entirely two years ago.
I have Sigil and other ebook tools. I'm not interested in editing or crafting eBooks. Only interested conversion from odt (Linux version of Calibre doesn't read .doc unlike Windows version) automatically to mobi, azw and epub for my own proof annotations (saved more than cost of two Kobo H2O in paper & toner, also faster to put corrections in). Also to give copies to beta readers and have an idea how it might look for people buying from Amazon, Smashwords or Smashwords distribution.

Anyway, Calibre is great on Linux and was great on XP. The drivers and plug-ins are appreciated. None of it is obvious for even experienced users coming to the "system" fresh. It's awkward too when you move OS or install on an additional laptop that I can easily archive and restore the titles, but having all the same plug-ins and drivers with all the same settings seems awkward.
Also things seem to unexpectedly change. Was it the firmware on a Reader? All the other models / brands seem OK? Or a Calibre update, or driver, or plug-in, or a setting or even the Linux Desktop? There are very many settings.
Also most OS, Software , HW it's now nearly impossible to contact anyone. Or get more than a Lawyer sanitised Marketing reply from an offshore call centre. MS doesn't even listen to the feedback on the Insider program.

I'm not making any definitive suggestions as to how anything should be changed. Just suggesting that only I personally didn't understand the significance of what I was reading on descriptions, dialogue text and the tool tip hover text.

Sometimes it seems that stuff works differently to last week and you have to change a setting you didn't change ever, or changed it so long ago. I noticed last night after reloading around 1000 books as ePubs instead of kepubs SOME epubs were ignoring the Kobo GUI user setting for Line Spacing. Obviously too tight for accented capitals on a line below descenders. Calibre had 120% minimum line spacing. I tried ALL the options in paragraph style in LibreOffice Writer (no effect). Only setting the minimum line spacing to 0 in Calibre allowed the GUI on the Kobo to increase the line spacing. Obviously while 120% is typical, it's not enough for some combinations of fonts, accented capitals and descenders. Puzzling as I'm sure I used to be able to vary line spacing on the Kobo on ALL the books before. Also "Minimum Line spacing" option sets a line spacing in the body css which the Kobo seems to regard as a fixed line spacing of 120% (or whatever you set it to), ignoring user GUI control.
Overall page L & R margin is adjustable and the same default on the Kobo GUI, no matter what the LibreOffice .odt or MS Word .doc page margins, headers & footers are.



EPub, AZW and Mobi creation by myself is ONLY for private use.

[DNSB]

Originally Posted by FrustratedReader

A screen shot would have told nothing more except I wasn't making it up.

The only sensible "content creation" tool to write is a wordprocessor. The output has to be PDF for POD and ms .doc or .docx to upload to Amazon. Only Google Books requires ePub upload for Google Play, though they seem to prefer PDF, which is stupid.

If you are planning on print documents, sure. If you are not planning on print documents, sensible is not quite the word I would use. As for upload to Amazon, they accept formats other than .doc or .docx. Epub is accepted and gives, in the opinion of several authors I know, the closest match between formating in the input and the azw3 output. The need to unzip the epub before uploading is a bit of a pain. OTOH, have you ever read the Amazon disclaimer on uploading a .doc/.docx file? The one that reads: "Most DOC/DOCX files convert well to eBooks. However, some files with complex formatting may not convert as well."

Originally Posted by FrustratedReader

Paper requires absolute measurements.

And a knowledge of what size the output paper is. Is it letter? A4? Tabloid? booklet? No better than using absolute measurements on a webpage where the resolution of the display is unknown.

Originally Posted by FrustratedReader

MS doesn't even listen to the feedback on the Insider program.

I would disagree there. I've been involved in several Microsoft beta programs. I've found they do listen to the feedback though sheer volume of complaints was the deciding factor. For the Windows 10 and Server 2019 insider programs, the recent ability to flag bug severity is a welcome improvement compared to their older sheer quantity of complaints severity ratings.

Originally Posted by FrustratedReader

Sometimes it seems that stuff works differently to last week and you have to change a setting you didn't change ever, or changed it so long ago. I noticed last night after reloading around 1000 books as ePubs instead of kepubs SOME epubs were ignoring the Kobo GUI user setting for Line Spacing. Obviously too tight for accented capitals on a line below descenders. Calibre had 120% minimum line spacing. I tried ALL the options in paragraph style in LibreOffice Writer (no effect). Only setting the minimum line spacing to 0 in Calibre allowed the GUI on the Kobo to increase the line spacing. Obviously while 120% is typical, it's not enough for some combinations of fonts, accented capitals and descenders. Puzzling as I'm sure I used to be able to vary line spacing on the Kobo on ALL the books before. Also "Minimum Line spacing" option sets a line spacing in the body css which the Kobo seems to regard as a fixed line spacing of 120% (or whatever you set it to), ignoring user GUI control.
Overall page L & R margin is adjustable and the same default on the Kobo GUI, no matter what the LibreOffice .odt or MS Word .doc page margins, headers & footers are.

That respect for embedded CSS in epubs has been there since the early days of Kobo ereaders. If you specify a line height for an element, the slider will have no effect. The L/R margin slider can only increase the margins specified in the the epub style and not decrease it. If some maroon decides to specify a font size in absolute measurement...

You might want to look into using the calibre editor or Sigil to work on the epub instead of depending on calibre's conversion. Sigil with the preview windows on a second monitor is my preferred environment.

[davidfor]

Originally Posted by FrustratedReader

A screen shot would have told nothing more except I wasn't making it up.

That is BS. A screenshot would have told us:

• Exactly what it looked like. We believed you, but demonstrating what you saw is always a good idea as maybe we misinterpreted something you said. And as I couldn't reproduce it, I needed some guidance.
• That you were using kepubs not epubs. The title bar would have told us that.
• Or, that you were using the unsupported fullscreen mode which had bugs. And that might have been the cause of the problem. The discussion following that would probably have revealed that you were using kepub.

My point is that you did little to help us help you. The screenshots and sample would have made sure we were all talking about the same thing.

I'm not going to comment on how to produce a book as it isn't my thing. Except to say that I any time I have looked at the code of a book from Smashwords, it is so bad that I sometimes wonder why it actually works. My opinion would be that if you care about the look of a book, you should create and fine-tune the epub and submit that.

Anyway, Calibre is great on Linux and was great on XP. The drivers and plug-ins are appreciated. None of it is obvious for even experienced users coming to the "system" fresh. It's awkward too when you move OS or install on an additional laptop that I can easily archive and restore the titles, but having all the same plug-ins and drivers with all the same settings seems awkward.

Calibre has a mechanism designed for moving a library from one machine to another. I'm pretty sure this includes the configuration.

Also things seem to unexpectedly change. Was it the firmware on a Reader? All the other models / brands seem OK? Or a Calibre update, or driver, or plug-in, or a setting or even the Linux Desktop? There are very many settings.

In the time-frame you are talking about, nothing should have changed. Nothing in the firmware or calibre drivers changed. I'm pretty sure nothing in the areas of calibre you use would have had a noticeable change. Any changes were differences were more likely in the book.

Also most OS, Software , HW it's now nearly impossible to contact anyone. Or get more than a Lawyer sanitised Marketing reply from an offshore call centre. MS doesn't even listen to the feedback on the Insider program.

I haven't needed to contact anyone like that for years. I search the web and find somewhere that answers the question. Here is the best place I have found for ebooks and ereaders.

I'm not making any definitive suggestions as to how anything should be changed.

It definitely sounded like you were. But my response was because I thought you suggestion was a lot worse than what is currently

Just suggesting that only I personally didn't understand the significance of what I was reading on descriptions, dialogue text and the tool tip hover text.

Sorry, but I have no sympathy for that. If you don't understands something, don't use it until you do. Surely a person with over 30 years of development experience knows that.