a fájlformátum problémák könnyen tesztelhetők automatikusan a legtöbb esetben ‒ Összehasonlítva a megjelenítéssel vagy felhasználói felülettel ‒ Tehát nem egy végtelen küzdelem – egy adott problémát tekintve • Rossz hír: a legtöbb esetben a forráskód módosítása szükséges ‒ A bemeneti fájl tartalmának módosítása ritkán segít
amikor a problémát egy import vagy export szűrő okozza • Jó példák: ‒ Egy vonal vastagsága túl nagy, ha egy csoportos alakzat részét képezi, DOCX megnyitása esetén ‒ Ez a dokumentum egy oldalas kéne legyen, nem kettő • Rossz példák: ‒ A betöltött dokumentum megjelenítése fagyást (hang) okoz ‒ A Writer nem támogat egy adott funkciót, amit a fájlformátum viszont támogatna
• “Megnyitás” a felhasználói felületen: import egy üres dokumentumba, majd visszavonás-lista ürítése • “Kivágás és másolás” a felhasználói felületen: részleges export, majd import egy létező dokumentumba • “Mentés” a felhasználói felületen: export egy létező fájl útvonalra • Ez a magyarázata annak, hogy: ‒ Egyetlen karakter leütése + mentés teljesen átírja a fájlt ‒ Miért nem lehet csak a „konverziós gépezetet” kiemelni a kódból (de: van headless mód)
import/export veszteségmentes • Az ODF szemantikája nagyon közel áll a Writer modelljéhez: ‒ Példa paragrafustokra: UNO tulajdonságok ↔ XML attribútumok • Az implementáció nagy része az UNO API-t használja ‒ Jó példaként szolgál más szűrők fejlesztésekor • Forráskód: xmloff/ és sw/source/filter/xml/ alatt • ODF ellenőrző: ‒ http://odf-validator2.rhcloud.com/odf-validator2/
mint a HTML, de támogat minden szövegszerkesztő funkciót (oldalméret, hasábok, stb.) ‒ A gyakorlatban sokszor nehezen olvasható • Export ‒ LibreOffice 3.3-ban jelent meg a jelenlegi implementáció ‒ Belső szűrő, kód megosztás a DOC/DOCX szűrőkkel • Import ‒ LibreOffice 3.5-ban jelent meg a mostani megvalósítás ‒ UNO szűrő, a domain mapper közös a DOCX importerrel • Nagyrészt én követtem el
Ha nem számoljuk a binfiltert • Mind az import és az export belső szűrő • A specifikációja [MS-DOC] néven elérhető • A tokenizáló és a domain mapper nincs elkülönítve • Az mso-dumper DOC támogatása segíthet: ‒ http://cgit.freedesktop.org/libreoffice/contrib/mso-dumper/ • Az import/export kód részben megosztott
Példa: left/right vagy start/end a paragrafusok margóinak leírására • Az import régebbi ‒ Túlbonyolított, a writerfilter/ alatt ‒ A tokenizer kódját egy XSLT generálja, nehéz benne hibát keresni ‒ OpenOffice.org-ból örökölt, UNO alapú ‒ A domain mapper közös az RTF szűrővel • Az export csak a LibreOffice része ‒ Belső ‒ Kód megosztás a DOC/RTF szűrőkkel
megbirkózik- e a fájllal ‒ CVE tesztek ‒ Ha a szűrő a megfelelő visszatérési értéket adja, készen vagyunk • Belső tesztek ‒ Hozzáférés a privát Writer szimbólumokhoz ‒ Praktikus itt tesztelni azokat a metódusokat amiket a UI használ ‒ A szűrőket tipikusan nem itt teszteljük
Töltsük be a fájlt, majd értékeljünk ki kifejezéseket az UNO modellen • Export ‒ Import → export → import ‒ Így azonos API használható mindkét esetben, és az importot is teszteljük ‒ Alternatíva: kódból felépíteni a dokumentumot, majd valahogy megvizsgálni az eredményt (XPath az XML-alapú formátumokhoz, de mit kezdjünk a többivel?) ‒ Hátrány: az import is jó kell legyen ‒ Egyébként sem baj
alapértelmezett oldalstílus fejlécének tartalma ‒ Hanem: a harmadik oldalon lévő fejléc szövege • Néha hasznos, de óvatosnak kell lenni ‒ A Writer megjelenítése részben a háttérben fut, a tesztek erre nem várnak ‒ A megjelenítés különbsége nem biztos, hogy baj ‒ Például hiányzó betűtípus
content in this document, unless otherwise specified, is licensed under the Creative Commons Attribution-Share Alike 3.0 License . This does not include the LibreOffice name, logo, or icon. All SUSE marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States.