No way to create root-level <title> element

[codedread]

From the SVG spec [1]:

"Authors should always provide a 'title' child element to the outermost 'svg' element within a stand-alone SVG document."

Now that title and desc are editable via the Object Properties dialog, it seems appropriate that the author should be able to set the document's title. At the moment I do not see a way to do this.

File > Document Metadata > Title sets the title element within the metadata rdf.

[1] http://www.w3.org/TR/SVG11/struct.html#DescriptionAndTitleElements

[sas (sas-sas)]

I think the RDF document title and description ought to be kept in sync with top-level 'title' and 'desc' elements, because they have the same meaning.

Keeping them in sync all the time may be a bit awkward, as it would mean that they need to be synced when a document is opened, and kept in sync if the user edits one or other with the XML editor. There's also the question of what to do if a document specifies a title in both SVG and RDF, and the two titles are different. But we should at least ensure that setting a title or description in the Document Metadata dialog results in a top-level 'title' or 'desc' element, as well as the 'dc:title' or 'dc:description' element that is currently used, and that would be enough to fix this bug.

[sas (sas-sas)]

Also, I think it would be useful to have a title field in the save dialog. That way, people are much more likely to add a title (or change an inappropriate one).

[codedread (codedread)]

sas - you read my mind :)

This was going to be my next step after this bug (revamp the Save dialog a little and add a Title edit box).

[codedread (codedread)]

sas - fyi, the title field in the save dialog is covered by this bug: https://bugs.launchpad.net/inkscape/+bug/209199

[codedread (codedread)]

Patch that syncs metadata dc:title to document-level title. I would like to submit another patch that syncs title to dc:title upon load (but only when dc:title does not yet exist).

[codedread (codedread)]

Hm, just tried this patch in Linux and apparently it does not work (extension/internal/svg.cpp cannot see the sync-metadata.h file?).

Anyway, since this patch will ultimately just be two functions, I'd like to instead add these functions to some suitable .cpp file already existent. This will also reduce the patch size and prevent yet another object file that has to be linked. Any suggestions?

[sas (sas-sas)]

Maybe the best way to do the syncing is with title() and setTitle() member functions for SPDocument (in document.cpp). The title() function would call title() on the root element, and if that returns NULL would then attempt to get the title from the document metadata. The setTitle() function would call setTitle() on the root element, and would also set the title in the document metadata.

[codedread (codedread)]

sas,

The syncMetadataTitleToDocTitle() in my patch (called during a Save) does the following:

- gets the document metadata title
- applies it to the document element (overwriting any existing title)

The problem with first checking title() is this: let's say the user saves their document with a metadata title one time. In this case, the document gets a new svg:title element. Then they realize they made a mistake and correct it under File > Document Metadata. If we implement what you're suggesting, the <title> element will stay frozen and diverge from the <metadata>'s dc:title element. Thus, I think the only right way to do this is to state that (for now) metadata's dc:title always overwrites the document's svg:title.

I do like the idea of moving this into the SPDocument class (removes the need for a makefile update and another object file). I'll do that in my subsequent patch.

[sas (sas-sas)]

My intention was that the Document Metadata dialog should call SPDocument::setTitle() to set the title, rather than what it's doing now. In fact, everything that changes the document title should use SPDocument::setTitle(). This way, the two titles can never diverge (except perhaps if the user edits them through the XML editor - I don't know how easy it is to catch that).

(The Document Metadata dialog should also read the title using SPDocument::title(), rather than just looking at the 'dc:title' element.)

[codedread (codedread)]

Sure, I can hack on stuff for the Document MetaData window so that the "Title" field is treated differently than the other fields (it's just that right now, all fields are treated equally and simply set the metadata element in XML).

The problem is that we have two elements that mean, semantically, the same thing. From a UI perspective, we want to put one face on that (allow the user to change one field and it propagates to both elements), but it is possible for someone to hack on the XML text (or use the XML editor) to introduce differences in these two elements - so we need to carefulliy think about this.

Let's say we have the following XML doc:

<svg...>
  <title>Foo Title</title>
  <metadata>
    <rdf:RDF>
      <cc:Work>
        <dc:title>Bar Title</dc:title>
      </cc:Work>
    </rdf:RDF>
  </metadata>
</svg>

a) When loading up in Inkscape and opening the Document Metadata dialog, what should be shown to the user (probably "Bar Title" since that's what has been done in the past consistently). This is counter to your last comment in parentheses where you suggested using title().

b) If the user does not modify anything, when the Document Metadata dialog is closed, does it call setTitle() to make <title> have "Bar Title" ? This means Inkscape is changing the document without any user interaction, but maybe this is ok. In fact, I think I want to go down this route to ensure synchronized elements.

c) If the user modifies the Title entry field in the UI (in Document Metadata dialog), to "baz title", I assume that both <title> and <dc:title> get the new value.

d) Let's say the user saves it as Plain SVG. Currently <metadata> elements are removed. Should we start preserving <metadata> elements in Plain SVG?

e) If <metadata> was not present and the Document Metadata dialog is opened, I think only in this case should the title() value populate the Title entry widget. Do you agree? In this case, we would be making sure the newly created <metadata> element is in sync with <title> upon creation (and once it's created, it becomes the 'master' again).

[codedread (codedread)]

Ok, here's my second attempt. This patch completely obsoletes the first patch and is much simpler based on sas' feedback and my thoughts in the above comment.

This patch:
- always sets the document's <title> to the RDF title value
- upon bringing up the metadata dialog, if the RDF title is not set, set it to the document's <title> if it exists
- if the user does not modify the title in the metadata dialog, it will leave the document's <title> alone

This has the effect of keeping the RDF and document title's in sync when edited via the metadata dialog (and future UI elements). However, it also allows a user to manually edit the SVG source and differentiate between the titles as long as they are careful not to edit the title in the metadata dialog.

[codedread (codedread)]

Committed patch to trunk

[Jon A. Cruz (jon-joncruz)]

I think this one should be marked as complete. If additional specifics (such as window titlebar adjustments, etc) are needed, then they should go in as separate bugs.