Extra metadata import from ODT - Page 4

olig · 08-01-2012, 07:21 AM

I'm not proposing to work on individual elements, but on all of them. But I understand you point of view.

Would you accept this as input filter (i.e. ODT in specific) option? Sorry, but I have to ask before I do it as a wrapper. I promise this is my last try

But...

While thinking about this, I thought about plugins. But there is currently no way you can put a conversion plugin between input and output (in the plumber). This would open up the architecture for all sorts of markup and style optimization, while keeping the core functionality of Calibre clean. But obviously this would be much more work.

kovidgoyal · 08-01-2012, 10:10 AM

Is changing all margins indiscriminately a safe thing to do? What if some margins are used for layout?

olig · 08-01-2012, 11:02 AM

That obviously depends and is in the hand of the user. Using --filter-css might also destroy layout, as might any other option that messes around with CSS. But that's why it is an option, so you can try if it helps or let it be if it does not.

kovidgoyal · 08-01-2012, 02:19 PM

Yes, using the vast majority of options in the conversion can lead to loss of formatting or even data (s&r being a case in point). Look at it this way. You can use filter-css as a global setting, say to remove document specified colors for all your books if you like using night mode in a viewer. You can do this without having to know anything about the actual css in your book. The same applies to --base-font-size etc. Whereas to use search and replace on css you have to know what the css in the individual book you are converting is.

Now obviously, this is not a clear partitioning. Various tasks fall somewhere in between editing and not editing. And there are parts of the conversion pipeline, like s&r, that I would say are more editing than not. Nonetheless, it is my judgement that adding CSS s&r is not appropriate for calibre. CSS by its very nature is hard to run s&r on without fully understanding how it applies to the html, since it is not easy to predict what change will have what visual effect, without understanding both the css and the html to which it is applied. The proper place to do this is in a book editor.

olig · 08-02-2012, 03:08 AM

You did now talk especially about the first idea with the s&r, but I did mainly talk about consistent scaling. And what else is changing the base font size? Actually changing the base font size without changing other distance (I purely talk about going from print layout to ebook layout as in ODT->ebook conversion) is the thing that destroys the layout.

Blindly changing margins is no good, you are right.

So I'll do the wrapper script.

kovidgoyal · 08-02-2012, 03:14 AM

The problem is that while it is possible to scale all font sizes fairly consistently in an automated fashion, it isn't possible to do that with other lengths. How can an automated process know when a particular length is appropriate to be scaled?

In general, the problem of going from a fixed layout to a reflowable one automatically is hard to solve.

08-02-2012, 03:08 AM	#50
olig Enthusiast Posts: 32 Karma: 12 Join Date: Jul 2012 Device: Kindle 4nt 4.1.3 jailbreak	You did now talk especially about the first idea with the s&r, but I did mainly talk about consistent scaling. And what else is changing the base font size? Actually changing the base font size without changing other distance (I purely talk about going from print layout to ebook layout as in ODT->ebook conversion) is the thing that destroys the layout. Blindly changing margins is no good, you are right. So I'll do the wrapper script. Last edited by olig; 08-02-2012 at 03:18 AM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Auto Download Metadata on Import	ebookrights	Calibre	2	12-18-2012 10:51 AM
Import MetaData an Tags	adrian142	Library Management	0	04-03-2012 11:40 AM
Import metadata from file	Vinavil	Library Management	2	01-28-2012 03:48 PM
Mixing metadata on import	PeteMan	Calibre	2	01-03-2011 02:21 PM
Import: prioritization of metadata source?	ATimson	Calibre	2	02-28-2010 03:57 PM

08-01-2012, 07:21 AM	#46
olig Enthusiast Posts: 32 Karma: 12 Join Date: Jul 2012 Device: Kindle 4nt 4.1.3 jailbreak	I'm not proposing to work on individual elements, but on all of them. But I understand you point of view. Would you accept this as input filter (i.e. ODT in specific) option? Sorry, but I have to ask before I do it as a wrapper. I promise this is my last try But... While thinking about this, I thought about plugins. But there is currently no way you can put a conversion plugin between input and output (in the plumber). This would open up the architecture for all sorts of markup and style optimization, while keeping the core functionality of Calibre clean. But obviously this would be much more work.

08-01-2012, 10:10 AM	#47
kovidgoyal creator of calibre Posts: 43,860 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Is changing all margins indiscriminately a safe thing to do? What if some margins are used for layout?

08-01-2012, 11:02 AM	#48
olig Enthusiast Posts: 32 Karma: 12 Join Date: Jul 2012 Device: Kindle 4nt 4.1.3 jailbreak	That obviously depends and is in the hand of the user. Using --filter-css might also destroy layout, as might any other option that messes around with CSS. But that's why it is an option, so you can try if it helps or let it be if it does not.

08-01-2012, 02:19 PM	#49
kovidgoyal creator of calibre Posts: 43,860 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Yes, using the vast majority of options in the conversion can lead to loss of formatting or even data (s&r being a case in point). Look at it this way. You can use filter-css as a global setting, say to remove document specified colors for all your books if you like using night mode in a viewer. You can do this without having to know anything about the actual css in your book. The same applies to --base-font-size etc. Whereas to use search and replace on css you have to know what the css in the individual book you are converting is. Now obviously, this is not a clear partitioning. Various tasks fall somewhere in between editing and not editing. And there are parts of the conversion pipeline, like s&r, that I would say are more editing than not. Nonetheless, it is my judgement that adding CSS s&r is not appropriate for calibre. CSS by its very nature is hard to run s&r on without fully understanding how it applies to the html, since it is not easy to predict what change will have what visual effect, without understanding both the css and the html to which it is applied. The proper place to do this is in a book editor.

08-02-2012, 03:14 AM	#51
kovidgoyal creator of calibre Posts: 43,860 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	The problem is that while it is possible to scale all font sizes fairly consistently in an automated fashion, it isn't possible to do that with other lengths. How can an automated process know when a particular length is appropriate to be scaled? In general, the problem of going from a fixed layout to a reflowable one automatically is hard to solve.