OpenLyrics: Új elemek

[gyuris]

Felbontva a #7-t:

A probléma leírása: Van néhány egybefüggő probléma abból fakadóan, hogy a szöveg és az akkord hossza nincs szemantikailag egymáshoz rendelve. Ez megjelenésben azt jelenti, hogy jelenleg az akkordról csak azt tudjuk megmondani, hogy a szöveg egy bizonyos pontján helyezkedjen el, mégpedig onnan jobbra folyva:

1. Felütések: Időnként a szöveg elé kell rakni az akkordot.
2. Szünetjeles (=sor végén álló) akkordok: időnként több akkordot kell írni a sor végére (vagy a sor elejére), de ezek a egymásra folynak.
3. Akkordok szöveg nélkül: a szöveg nélküli versszaktípusokban az akkordok szöveg nélkül kell álljanak, de ezek szintén egymásra folynak, mert nincs hosszuk.
4. Akkordok és szótagok hossza: Ha gyorsan jön egy akkordváltás, akkor ezek egymásra csúsznak, mivel nincs hosszértékük a szöveghez viszonyítva.

A problémát akkor érthetjük meg legkönnyebben, ha a ennek a javaslatnak a 3D-s dobozmodelljét szemügyre vesszük:

• A neon-zöld színű akkordok simán csak jobbra folynak. Látható, hogy az akkor maga „nem tudja” mekkora helyet foglal a szöveg, amire érvényes.
• A sárga színű akkordok viszont a szövegre vannak írva. Látható is a dobozmodellje, ahogy kiemelkedik, ez azt jelenti, hogy az akkord tudja mennyi helyet foglal a szöveg és ha szükséges, akkor kijjebb nyomja a doboz jobb oldalát (így keletkezik az elválasztójel a hátterében).

A példa refrénjének 2. és 4. sora közt a különbség:

Ho<chord name="A" />sanna in the <chord name="C#m" />high<chord title="B" />est.
Ho<chord name="A">san</chord>na in the <chord name="C#m">high</chord><chord name="B" />est.

Az (1) problémára megoldás

<chord position="before" name="A" />I see His love and mercy

El lehet azon gondolkodni, hogy a position="after" vagy a position="middle" szükséges-e?

Első javaslat a többire

Két akkord írásmódot kell engedélyezni, melyek mást jelentenek szemantikusan és máshogy is kell őket megjeleníteni:

• A normált, ahogy eddig írtuk csak akkor használjuk, ha nincs kapcsolatban a szöveggel:
  • felütés (1),
  • szabadon álló sor végi vagy eleji akkordok esetén (2)
  • és a szöveg nélküli versszaktípusok esetén (3). Mivel ezt az akkordírást meg lehet különböztetni szemantikailag (CSS pl.: chord:empty) így le tudjuk kezelni a másik esettől.
• Minden szövegre írt akkordot szótagra írunk, így:

Ho<chord name="A">san</chord>na

Ezzel a javaslattal csak egy baj van: visszafelé nem kompatibilis. A 0.8-as verzióra készített akkordokra külön kell karbantartani egy egyszerű jobbra folyó nézetmódot (ez simán kezelhető a <song version="0.8"> alapján).

Második javaslat a többire

Ez a következő csomagot jelentené:

• A szövegben két módon lehet megadni az akkordokat. A hagyományosan írt akkordok értelmezhetőek és jobbra folynak, mint eddig. De a (4) probléma miatt lehet szótagra is írni. Így visszafelé is kompatibilis az akkordírás, de előremutató is.
• A (2) és (3) problémára be kell vezetni a 'nem énekelt szünet' fogalmát a szövegben, melynek a hosszát is lehet szabályozni az aktuális ütem egynegyedét véve alapértéknek. Pl.:

<chord name="A"><rest /></chord><chord name="G"><rest duration="2" /></chord>

Ez egyrészt:

• korrekt szemantika a szövegben és az előjátékban is
• másrészt meg is lehet jeleníteni egymásra csúszás nélkül, mert a szünetjelből megjelenítési dobozt lehet kreálni.

  Értékelés

Én az első preferálom, mert ez a legszebb szemantikai megvalósítás. Kérdés mennyire örülnek azok, akiknek már van egy halom akkordjuk OpenLyrics-ben.

[triszterer]

Szerintem, egyik megoldás sem jó. :-(

Két problémát látok:

1. Megváltoztatja az XML struktúráját és ezért nem lesz olyan program, amivel meg lehetne majd nyitni ezeket az álományokat. Arra nem számítanék, hogy esetleg miattunk módosítják majd a programokat. Mindképpen kompatibils megoldás kell.
2. A problémát rossz helyen, keressük. Mivel a probléma nem a definicióban keresendő, hanem megjelenítő program implementációjában. Félek, hogy 100%-ig korrekt megoldást - a HTML és a hozzá kapcsolódó techonológiákkal - adni nem lehetséges.

Csak hangosan gondolkodnék a lehetséges megoldásokól:

1. Fix széles karakter típussal jelenítjük meg a szöveget és az akkordokat. Igy az akkordok helyének a pozicionálását a szövegre bízzuk. Ha több hely kell az akkordnak, akkor a szöveget manuálisan széthúzzuk. Előjáték és közjáték esetén extra szóközökkel pozcionálhatjuk az akkordokat. Eddig amit láttam programot akkordokkal, azok asszem mind fixed széles karaktereket használtak.
2. Korrekt implementálása a doboz modelnek. Vélemenyem szerint a </chords> lezáró tag nélkül is kinyerhető az az információ, hogy meddig tart az akkord. Viszont nem egyeszerű történet a szöveg megyújtása.
   • Az elválaszó jeleket akárhova nem lehet betenni. A helyes elválsztáshoz az adott nyelv helyesírását ismerő szótag felismerő rendszer kellene. Ez asszem túl nagy falat.
   • Vagy csak simán széthúzzuk a szöveget. Ez meg ronda lenne.
   • Nem a szöveget nyújtjuk meg, hanem az akkordok jelölésén változtatunk. Pl. Ha egy akkord nem rakható a megfelelő szótag fölé (mert kitolódik az előző akkord miatt), akkor egy kis vonallal vagy más jellel jelöljük, hogy melyik szövegrészhez tartozik.

Egyik lehetséges megoldással sem vagyok elégedett. Igazábol csak gondolatébresztőnek szánnám őket....

Én asszem az első megoldásban gondolkodnék némi kiegészitéssel: Bevezetnék egy új elemet <space len="3"/>, amit a szöveg nyújtására használnék.

Jelen helyzetben, ha az akkordok egymásra csúszását megakadályozzuk, így nézne ki:

<lines><chord name="G#m7"/>Bo<chord name="C#m4"/>ci boci tarka</lines>

G#m7C#m7
Boci boci tarka

<space> node bevezetésével, így nézne ki:

<lines><chord name="G#m7"/>Bo<space len="3"/><chord name="C#m4"/>ci boci tarka</lines>

G#m7 C#m7
Bo - ci boci tarka

A len attributumban megadott érték egy relatív hossz érték kellene hogy legyen. Pl. az adott betütipusban az X karakter hossza. Ez a megoldás még mindig csak fixed betűtípusokkal működne tökéletesen. Nyilván a szövegeket és space-eket be lehetne "lőni" más betűtípusokhoz is, de ez a fajta függőség nem szerencsés.

Hát asszem probléma felvetésen én sem jutottam tovább...