Quote:
Originally Posted by Silek
The rendering problem you mention may be why I am not seeing the GUI entries. I am using the "multiple text, show in tag browser" column type.
|
Look at the metadata.opf file in the books folder in the library. They do not exhibit the problem.
Quote:
Now the order of the JSON fields is different, but I thought that would not matter.
|
It won't.
Quote:
The template entry for a custom field is:
My entry is:
<meta>
<name>calibre:user_metadata:#characters</name>
<content>
|
I have no idea if calibre's xml engine will consider this alternate structure as equivalent to its own.
Quote:
Due to the rendering problem, I do not have a good idea of what the entry is supposed to look like.
|
As mentioned above, you can see calibre's version in the metadata.opf file.
Quote:
I figure the #value# entry is wrong, but I am not getting an error from calibredb set_metadata. Since I did not get an error, I did not know to dig in to the format (or even, where in the format to look).
|
The question is whether or not the JSON decode will work. The decoder might not throw an error, but could come up with different values. For example, I note that your string constants in #value# are not quoted. JSON will probably ignore them.
Quote:
I am using this data type because I wanted these entries to show in the tag browser. I suppose I could use dc:subject tags and add then specifically as tags, and leave them as one long comma delimited string in a text field, but that feels kludgy.
|
There are a lot of types that show up in the tag browser, such as text, enumeration, text/multiple, composite w/show in tag browser checked. You should use the one that makes sense for your data.
I also note that your template declares that the multiple text entry contains names (the is_names in the display attribute). Why did you check that box for tags-like items?