Suggestions

[Jack_Graham]

MetaData Editor

Hi,

I just downloaded the latest version of Sigil and would like to see some changes to the MetaData editor.

Honestly, this is why I use Sigil.

1. I would like to be able to select several fields to delete. (Ctrl+click)

2. I would like the delete button on the keyboard to work as if I pressed the delete button in the editor.

3 Most important - In the newest version, the field is as big as the information, typed in on long line, which makes it impossible to read and or edit in the editor. Would like a column width and word wrap so can adjust as needed to be able to see/edit data.

[KevinH]

You do understand, if you want to make a large number of deletes/changes it would be simpler to edit the metadata directly in the content.opf.

The option+forward delete (or control forward delete on some platforms) in Sigil 0.9.6 will delete the highlighted metadata element. The delete key alone can not be used as it impacts text within the highlighted element.

As for field wrapping, I will see if there is something that can be done.

[BetterRed]

Originally Posted by Jack_Graham

Honestly, this is why I use Sigil.

If you only want to edit the metadata maybe this would suit you better ==>> EPub Metadata Editor

Note : I don't use it myself.

BR

[KevinH]

The underlying widget in the QTreeView is a QLineEdit and as such does not support word wrapping even if you tell it to. To fix this I will have to subclass QStyledItemDelegate and install it and then reimplement its size hints and paint methods.

This is a lot of work so I want to understand why this is needed since editing of long metadata items would be much easier in the content.opf as opposed to a field in a TreeView.

What exactly are you storing that takes up so much room you can't store it in the continously expanding space provided. No title, author, etc could have that long a name.

Are you trying to store an entire abstract into a dc:description element? Is that the reason this feature is needed? You can always manually resize the columns and the dialog and scroll bars will appear for items longer than your screen allows.

So please help me to understand what the real use case is? If it is to edit large blocks of text, then doing that in the content.opf is simply easier/better since you have large amounts of screen real estate to work in.

KevinH

[Jack_Graham]

Originally Posted by KevinH

You do understand, if you want to make a large number of deletes/changes it would be simpler to edit the metadata directly in the content.opf.

Well, yes, I do understand that. The unfortunate thing is the reason I make changes is do to my tablet reader - which does not use the opf file.

There are effectively two basic changes I make:

1st is to the author to make sure it is spelled correctly and in the correct format (FName LName) or (LName, Fname)
This is so all the book by the same author can be found together


2nd is the title (Series - # - Title)
This is so they can be sorted into reading order as opposed to alphabetical by title, which when you have 32 books in a series is impossible to remember which book is #7. So I rename them so I can sort them this way


Yes, I know, so more sophisticated readers can sort them by author, series, number, and title. But that is not what my family uses. And even if we did, I would still have to edit some books to correct them.

[Jack_Graham]

Originally Posted by KevinH

The underlying widget in the QTreeView is a QLineEdit and as such does not support word wrapping even if you tell it to. To fix this I will have to subclass QStyledItemDelegate and install it and then reimplement its size hints and paint methods.

This is a lot of work so I want to understand why this is needed since editing of long metadata items would be much easier in the content.opf as opposed to a field in a TreeView.

What exactly are you storing that takes up so much room you can't store it in the continously expanding space provided. No title, author, etc could have that long a name.

Are you trying to store an entire abstract into a dc:description element? Is that the reason this feature is needed? You can always manually resize the columns and the dialog and scroll bars will appear for items longer than your screen allows.

So please help me to understand what the real use case is? If it is to edit large blocks of text, then doing that in the content.opf is simply easier/better since you have large amounts of screen real estate to work in.

KevinH

Kevin,
you hit the head right on the nail.
It is about the dc:description element. Some people put a lot of work into this. Now some just copy the description from Goodread's or Amazon's descriptions. And as I mentioned earlier my tablet reader dose not use the opf files, so editing that does me no good.
But it is impossible to edit the descriptions in the meta data editor if it is wider than your screen because if you try to go past the first screen, your ability to edit disappears, and you have to go back to the start - so you can only edit the viable test on the 1st screen, anything where you have to move the bar to see is uneditable in the metadata editor.

My work around is to cut and past into another program, edit the text and text tags, and the cut and paste back into the editor completely edited.

Jack

[Toxaris]

Originally Posted by Jack_Graham

Well, yes, I do understand that. The unfortunate thing is the reason I make changes is do to my tablet reader - which does not use the opf file.

It will most definitely use the opf file. That is the location where the metadata is stored in an ePUB. The metadata editor is 'just' a tool to make editing the metadata part of the opf file easier and safer.

[Hitch]

Originally Posted by Toxaris

It will most definitely use the opf file. That is the location where the metadata is stored in an ePUB. The metadata editor is 'just' a tool to make editing the metadata part of the opf file easier and safer.

Indeed.

@Jack_Graham:

Tox is correct; there's no way that your eBook reader or reading software is NOT using the OPF. Unless your tablet is reading PDFs, there's really no way around this. There's no other place that the metadata is stored, especially if you are talking about the description.

So, why not use the metadata editor, or, as earlier suggested, just edit in the OPF itself, as you are using Sigil?

That's dramatically faster and easier than using the metadata editor, if we're discussing longer blocks of text.

Offered solely FWIW.

Hitch

[Pablo]

Originally Posted by Toxaris

It will most definitely use the opf file. That is the location where the metadata is stored in an ePUB. The metadata editor is 'just' a tool to make editing the metadata part of the opf file easier and safer.

When you edit the "dc:description" field in the opf, for what I see, you cannot write html tags directly. For example, to insert a "<p>" tag you have to write "&lt;p&gt;". Am I right?

[KevinH]

Yes, editing the content.opf is done in a code editor. Since embedded html tags would make the xml in the opf not well-formed, the < and > and & must all be properly "escaped". You can of course use embedded html tags inside metadata, it is just not something I suggest as the device typically formats these the way it wants if it displays them at all.

Kevin

[Pablo]

Originally Posted by KevinH

Yes, editing the content.opf is done in a code editor. Since embedded html tags would make the xml in the opf not well-formed, the < and > and & must all be properly "escaped". You can of course use embedded html tags inside metadata, it is just not something I suggest as the device typically formats these the way it wants if it displays them at all.

Kevin

I mainly fill the "dc:description" field so that it shows in calibre. My device (Sony PRS-T2) doesn't show ebook metadata, I don't know if other readers do.

I've seen some ebooks that not only use html tags in the metadata but also CSS classes.

[KevinH]

I know of no other reader besides Calibre that shows much of anything other that title, authors, and date but ... there are so many generations of readers out there now so who knows. The original reason for these other metadata fields was as search fields that are meant to be used to help catalog and index ebooks. Overly complex html/css can actually impact searchability, which is the primary reason for "metadata", but to each their own. As long as you keep things well-formed for xml parsing, you can put anything you like.

[jackie_w]

Originally Posted by KevinH

I know of no other reader besides Calibre that shows much of anything other that title, authors, and date but ...

Just FYI - Kobos can also display Series, Comments, Published date, ISBN, Language

[Jack_Graham]

Originally Posted by Hitch

Indeed.

@Jack_Graham:

Tox is correct; there's no way that your eBook reader or reading software is NOT using the OPF. Unless your tablet is reading PDFs, there's really no way around this. There's no other place that the metadata is stored, especially if you are talking about the description.

My reader (UBReader) can sort the books by Title or by Author or by date added. As for the OPF file - Nope, not there. There is not one OPF file on my tablet, and yet the reader can pull Author and Title from the metadata for sorting - and I can pull up the "description" to read as well. That is pretty much all it can do. OH, I can view the cover as well, as long as it is part of the EPUB data. It does not use separate image file (I've tested it by using on image in the EPUB and another Image File as cover and it only looks at the one in the EPUB.) So my reader only uses the EPUB file itself, Not the JPG and not the OPF - so I do not even transfer them to the tablet. And it access the metadata somehow.

[Toxaris]

Originally Posted by Jack_Graham

My reader (UBReader) can sort the books by Title or by Author or by date added. As for the OPF file - Nope, not there. There is not one OPF file on my tablet, and yet the reader can pull Author and Title from the metadata for sorting - and I can pull up the "description" to read as well. That is pretty much all it can do. OH, I can view the cover as well, as long as it is part of the EPUB data. It does not use separate image file (I've tested it by using on image in the EPUB and another Image File as cover and it only looks at the one in the EPUB.) So my reader only uses the EPUB file itself, Not the JPG and not the OPF - so I do not even transfer them to the tablet. And it access the metadata somehow.

And where do you think your reader gets that information? From the OPF. The OPF is inside the ePUB, without it no reader can function. Calibre stores an OPF outside the ePUB, but that is not the same OPF.
The OPF you can edit in Sigil is of course the one in the ePUB.

It might be a good idea to get some basic knowledge about the structure of an ePUB from the wiki.