Custom field 'Plain text, not shown in the tag browser', just like 'Title'

[BetterRed]

Hmmm, that's what I imagined it was - but I couldn't believe it. Back to the future, Compuserve, Usenet and all that. As you say 1980's stuff.

Encode your Blu-Ray movies and store them in the calibre database, now why would I want to do that - apart from 'cos I now can. Perhaps in the hope that someone will write a calibre plugin that reads a movie and reproduces the screenplay using reverse engineering - as an EPUB of course

BR

[PeterT]

Sounds like uuencode / uudecode or the more modern MIME

[DaltonST]

You could store all book covers and books themselves in a single database file. 1 file Calibre library. Base64 is usually zipped on encode and unzipped on decode to save space.

[DaltonST]

Modern web browsers convert the base64 images from text to what you see on the screen. Look at the web page source for wikipedia or google search, and do a find on base64. Google serves up many images as base64 text, and the browser decodes them to .png or .jpg or .gif that are displayed on your screen as a picture.

[kovidgoyal]

Originally Posted by eschwartz

But I could take a stab at it, although not until Sunday (I will be offline as usual on Shabbos).

No need, it's done

[chaley]

When I made the suggestion to add other content types I was mainly thinking about images. I can imagine several reasons someone would want an image (other than the cover) displayed in book details and also want that image to travel with the database.

More esoteric possibilities include:

• DaltonST's example of the set of covers for a book.
• A "zip" to hold the "extras" that sometimes come with books such as sample programs, separate from the "zip" that is the book itself.
• Multiple versions of a book.
• Multiple files of the same "format" (epub, pdf, etc)
• The table of contents of a proceedings containing the paper that is the "book"
• Word(-like) files that contain a user's notes.

The reason I suggested base64 is risk reduction. There are many "clients" that look at comments fields: internal calibre, plugins, third party apps, etc. All of these expect to find text that may or may not be HTML. These clients are almost certainly not prepared to handle non-text data, for example images. If they encounter non-text data a very likely outcome is a crash. Base64 results in valid text. Clients may display something strange, but they won't crash. If the developer cares then the client can be changed to do the right thing with the data.

FWIW: I would prefer a single drop down box that is not editable. That box would contain the content types known by calibre at that moment. Plugins could set the content-type to something else. The reason: if there is both a boolean and a content type then code must check both instead of only one. There is the possibility of mistakes where one is set but not the other. Lastly the meaning isn't always clear. Does plain_text == True + content-type == text/plain mean the same thing as plain_text + content-type == empty? Can I set a content type without setting base64?

Also FWIW: base64 is used in lots of current protocols. For example, email is often stored and transmitted in base64. As DaltonST said, base64 is used in HTML, for example in IMG tags with src="data:image/png;base64,...". One finds it in interchange formats such as XML and JSON when there isn't a convenient text representation of the data.

[kovidgoyal]

I really dont want to encourage people to start storing arbitrary binary data in the DB. Remember that the entire DB is always loaded into RAM. Storing files/images/etc. in the DB is really not a good idea.

As such I have implemented support for plain text and markdown, but that's about as far as I am willing to push this.

[chaley]

@Kovid: I should have remembered that you would think that way about adding significant "stuff" to the database. After all, we had that discussion recently. Apologies for bringing it up again, albeit indirectly.

I pulled the changes and (what a surprise ) they work.

I note that 'interpret_as' is overloaded to control on which side of book details the column appears, with short-text appearing on the left and the other three (html, long-text, and markdown) appearing on the right. This means that I cannot have a column containing only a hyperlink or some other short HTML item appear with a label in the left side of the panel.

I see why you didn't choose to use show_heading to determine which side of book details the items appears. That would overload its meaning in the same way "interpret_as" is being overloaded, removing an option that is useful.

The question: does it make sense to you to have another boolean to indicate that the item is to be shown on the left in book details? The boolean widget would be enabled only if show_label is true, or alternatively checking it would force show_label to be true. As far as I can see, the new boolean would be used only in render.py near line 101, where a choice is made to use ans.append instead of adding the value (and the label) to the list of comments. Something like:

                    if disp.get('show_heading'):
                        if disp.get('show_on_left'):
                            ans.append((field, row % (name, val)))
                            continue
                        val = '<h3 class="comments-heading">%s</h3>%s' % (p(name), val)

I tested it by using disp.get('show_on_left', True).

If you think this is an OK change to make but don't want to do it yourself, I can do it. It should touch only the column creation code and render.py.

EDIT: The changes were easy enough that I went ahead and pushed them.

[chaley]

@Kovid: create_custom_column.ui has disappeared from the source, replaced by setup_ui in create_custom_column.py. Shouldn't the inheriting from Ui_QCreateCustomColumn also be removed? I tried it and the dialog works fine with it gone, but I don't know what the side effects might be.

[kovidgoyal]

Originally Posted by chaley

@Kovid: create_custom_column.ui has disappeared from the source, replaced by setup_ui in create_custom_column.py. Shouldn't the inheriting from Ui_QCreateCustomColumn also be removed? I tried it and the dialog works fine with it gone, but I don't know what the side effects might be.

Yeah, this was an oversight, now fixed.

[kovidgoyal]

Originally Posted by chaley

@Kovid: create_custom_column.ui has disappeared from the source, replaced by setup_ui in create_custom_column.py. Shouldn't the inheriting from Ui_QCreateCustomColumn also be removed? I tried it and the dialog works fine with it gone, but I don't know what the side effects might be.

My rationale for not having a separate setting to control heading position is that it only makes sense to have the heading on the left if you expect the text to be relatively short (i.e. fit in one line). And if that is the case you might as well use a short text display type. It is however true, that one cannot currently use a short HTML column, which may be useful for showing a single link. So I am not particularly opposed to it. I will look at your PR tomorrow, as it is getting late here. Note that you will also have to change the new content server code, in book_details.pyj

[chaley]

Originally Posted by kovidgoyal

My rationale for not having a separate setting to control heading position is that it only makes sense to have the heading on the left if you expect the text to be relatively short (i.e. fit in one line). And if that is the case you might as well use a short text display type. It is however true, that one cannot currently use a short HTML column, which may be useful for showing a single link. So I am not particularly opposed to it. I will look at your PR tomorrow, as it is getting late here. Note that you will also have to change the new content server code, in book_details.pyj

Changes to book_details.pyj pushed.

[eschwartz]

Originally Posted by kovidgoyal

No need, it's done

So what you're saying is, you went ahead and implemented it yourself anyway?

Maybe chaley is not the only person who lacks self-control.

[DaltonST]

The key word is "it". What "it" was defined to be varied quite a bit by who was defining "it". What was just implemented is now the official definition of "it".

As the saying goes, 'if you want "it" done right, then do "it" yourself'.

[kovidgoyal]

Originally Posted by eschwartz

So what you're saying is, you went ahead and implemented it yourself anyway?

Maybe chaley is not the only person who lacks self-control.

As DaltonST said, there were a lot of alternate proposals floating around, so I realized that doing it myself would actually take less time than reviewing someone else's code and getting them to implement it in exactly the flavor I wanted. But, yeah, when it comes to self control with work, I suffer from a total absence