openlp-core team mailing list archive
-
openlp-core team
-
Mailing list archive
-
Message #12075
[Bug 745636] Re: OpenLyrics xml including OpenLP specifics
** Branch linked: lp:openlp
--
You received this bug notification because you are a member of OpenLP
Core, which is subscribed to OpenLP.
https://bugs.launchpad.net/bugs/745636
Title:
OpenLyrics xml including OpenLP specifics
Status in OpenLP - Worship Presentation Software:
Fix Released
Bug description:
I'll raise this bug here, since we're going to have to do something
anyway in OpenLP, but it might need to lead to a wider discussion
which would need to spill over into the OpenLyrics group
(http://groups.google.com/group/openlyrics) because we may need to
extend the schema.
We're currently exporting tags like {r} and potentially [---] into
OpenLyrics XML. We can't do this because other software using will
just blindly display this as-is and it will look silly.
Raoul has suggested stripping it, which from the current OpenLyrics
point of view is the correct action to take. The problem is, if I want
to transfer some of my nicely coloured in songs from one V2
installation to another, and I take the Export Songs route, I'm going
to be a little upset that it hasn't taken my {formatting} with it.
Therefore we are going to either need to provide a specific v2 format
export which keeps the tags, or we're going to have to suggest to the
OpenLyrics group that we can have some form of tag that allows to
embed application specific information within the song. e.g. <bespoke
app="openlp">{r}</bespoke>My Red Text<bespoke
app="openlp">{/r}</bespoke>. Any program would need to check whether
the app is them, and if not just ignore the tag and it's contents.
Another option is suggest that OpenLyrics allows strict XHTML to be embedded, and so we just expand the tags and output the expanded information. Collapse again on import if a suitable tag value matches.
However when you have end users entering {r}'s but no {/r}'s or defining their own tags, this is going to be difficult, to enforce.
I think we also need to request a tag for suggested slide break (i.e. try and keep the text on one slide, but if you can't, this is where you should break). e.g. <break suggested="true" />. One for mandatory verse break would be good too <break />, but we already have v1a v1b in OpenLyrics, which I can't say I'm a big fan of since I feel <verse> should ideally contain a whole verse!
Looking at the schema, it could perhaps be an attribute on <line>, e.g. <line suggestedBreak="true"> and <line break="true">.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openlp/+bug/745636/+subscriptions
References