openlp-core team mailing list archive

[Andreas Preikschat <745636@xxxxxxxxxxxxxxxxxx>]

I don't think we'll be able to tackle this one before beta 2.

** Changed in: openlp
    Milestone: 1.9.6 => 1.9.7

-- 
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:
  Confirmed

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">.