Fórum pro uživatele kancelářského balíku OpenOffice | LibreOffice
 

#1 Re: Writer » "Vyčištění" odt - VYŘEŠENO » 15. 6. 2017 12:13:53

neutr napsal(a)

To co je z ukázky vidět jsou spíš tagy html než xml. Osobně jsem ještě html Writer neotevíral a tak se zase mohu jen domnívat, že html je vnořena do xml.


Není! Ono struktura xml a html si zase tak moc nepodobná není. je to konec konců příbuzná forma. To co pan kolega ukazuje je skutečně kopie kusu "kódu" z content.xml


pro jednoduchou názornost nad tím včerejším problémem s přehazováním jazyka viz:


https://www.dropbox.com/sh/0lq4qrqc7mak … 9R97a?dl=0


Všechyn tři soubory výše jsou z jednoho zdroje, jen se liší forma exportu/uložení.

#2 Re: Writer » "Vyčištění" odt - VYŘEŠENO » 15. 6. 2017 11:58:55

Ještě by mohl být problém s nadbytkem existujících stylů. případně zmatkem v prostřídávání se stylů (nejběžnější je zmatek mezi výchozí a tělo textu, které se podaří občas nadělat při překopírovávání bloků textu mezi rlznými soubory s různě nastavenými styly. Tyhle dva základní jsou nejběžnější a můžou se u různých autorů vyskytovat různě. Případně člověk sám může mí v různých souborech nastaveno různě. A bývá dobré toto sjednotit na jeden styl než mít oba tyto základní v textu a pak se při změně stylopisu např. Výchozího stylu vztekat, proč se mi část textu nezměnila (když je ve skutečnosti přiřazena ke stylu tělo textu).


Každopádně první co bych udělal je jak píše kolega lp. přijmout (nebo dle potřeby odmítnout) sledované změny, ať se netáhnou dále, ale jsou zapracovány. Tím se zbavíte zbytečně taženého balastu po věcech co jsou již k nepotřebě.


Je samozřejmě otázka zda změny přijmout šmahem bez kontroly en bloc a nebo je po jedné (a otrocky, ky) projít, ale mít zase jistotu, že mezi nimi nebyla žádná, kterou by bylo třeba ještě vyřešit.

#3 Re: Writer » "Vyčištění" odt - VYŘEŠENO » 14. 6. 2017 16:03:26

neutr napsal(a)

Problém s velkými soubory existoval a zřejmě ještě existuje, ale někdy to lze řešit pomocí odkazem vložených sekcí. Potom skutečný obsah souboru (většinou Hlavní dokument) nemá velikost embedding vložených sekcí a objektů. Bohu žel nevím jestli právě toto nepoužíváte a dokonce ani to jestli z takto odkazovaného dokumentu lze exportovat do html případně PDF.

Z hlavního dokumentu exportovat do pdf lze, technicky je to stejné jako jeden dokument. Rozdíl mezi en bloc knihou v jednom odt a sestavenou dynamicky přes odm je pouze v tom, že se neukládá jako jeden velký dokument. Kompletní dokument se generuje až po načtení odm do počítače načtením zodkazovaných částí.

nativní exporty do HTML a PDF jdou bezproblému. Co vím tak je problém s exporty do formátů, které jsou zavedeny nějakým rozšířením (jmenovitě třeba Writer2Latex), to je většinou problém, že funkce není v rozhranní hlavního dokumentu povolena/definována.

#4 Re: Writer » "Vyčištění" odt - VYŘEŠENO » 14. 6. 2017 15:52:49

jik napsal(a)

<span lang="cs-CZ">Longworth
</span><span lang="cs-CZ">také </span><span lang="cs-CZ">uvádí, že
zajímavým a nečekaným důsledkem </span><span lang="cs-CZ">zrušení
nevolnictví</span><span lang="cs-CZ">, který měl nakonec fatální
d</span><span lang="cs-CZ">opad,</span>

Tahle konkrétní chyba je daná tím, že pro jednotlivé části textu je nastaven "jiný" jazyk.
Je trochu obskurní, proč se to vyskytuje poněkud nelogicky na bezprostředně následujících částech věty, které jsou všechny psané jazykem jedním. Neřeknu, když by člověk vkládal citaci z.b. anglického textu dorpostřed českého odstavce, kde za citací následuje překlad a vysvětlení.


Pro tenhle konkrétní problém by mělo stačit nastavit jazyk dokumentu na češtinu (Nástroje/Jazyk/pro celý text/čeština).

#5 Writer » Hlavní Dokument - obrázky a tabulky v textu - posun pozice » 6. 6. 2017 11:26:05

majtas.d
Odpovědí: 0

Máte někdo další zkušennost s Hlavním Dokumentem? v LO 5.2 a 5.3?

Dle dokumentace by měl být hlavní dokument tvořený dílčímy dokumenty identický, potud pokud má hlavní dokument stejně jako dokumenty do něj přiřazené stejnoustylistiku. Respektive pokud vychází z jedné šablony.

Problém na který jsem narazil je ten, že toto, zjevně není pravda. Pokud mám v dokumentu někam vložený objekt (rovnice, obrázek, tabulka), vázaný pozicí na odstavec nebo znak. A takto napozicované objekty mám nastavené tak aby je tech nějak smysluplně obtékal. a Věc opticky vypadala (tj pak vložený objekt odsunut např hornímu nebo dolnímu okraji textové oblasti.
V momentě kdy z těchto dokumentů sestavím Hlavní dokument (opět vše má stejnou šablonu), dochází k posunu textu. Styly odpovídají, ale někde dochází k nafukování Mezer mezi řádky, respektive odstavci.

Co jsem zatím vysledoval tak ač oboje je v jednou programu, se mezera pod a nad odstavcem ve stylu chová v běžném dokumentu DOT jinak než v hlavním dokumentu ODM!

Zatímco v běžném dokumentu se při styku dvou odstavců s různým odsazením od sabe zsapočítá to větší. U hlavního dokumentu se mi mezera sčítá. Všiml jsem si toho náhodně u záhlaví dokumentu, které bylo vyvedeno douřádkově ve smyslu "Název Knihy" \n "Název Kapitoly". Ale problém s postupným odsouváním textu a tím pádem na něj navázaných vložených objektů tím nezanikl. Takže někde ještě v textu přetrvává.

Problém se dá pravděpodobně "na vepřovo" obejít předefinováním mezer mezi odstavci, aby bylo na buď vždy před, nebo vždy pod. Ale to není systémové řešení.

Moje otázka je, má někdo podobnou zkušennost? Než začnu posílat další příspěvek do bugzilly rád bych eliminoval chybu na mojí straně.

Díky.

----

Projevuje se mi to na několika instalacích ve verzích 5.2.6 - 5.3.3.
Na systémech Win Xp-Win7, ale pochybuju, že tohle je vina systému.

----

[Edit1]
Problém otestován pozitivně i na AOO 4.1.3, chová se v konstce identicky, ale záhadným způsobem posouvá maličko jinak. Když vedle sebe odentický master dokument otevřu v LO a AOO a dám si vedle sebe dva náhledy téhož, je text v obou posouván jinak! V obou případech se jedná o ten samý dokument (resp dvě identické kopie) a v obou případech je v AOO i LO včleněna identická šablona dokumentu.

Jinak detekován druhotný problém se zpracováním oddílů v LO (v AOO zatím nepotvrzeno). Při zacházení s delším dokumentem (odhadem na 250 stran, detekováno to je na hlavním dokumentu okolo 400 stran), dochází při aktualizaci takovéhoto hlavního dokumentu ke vzniku artefaktů.

Paměti je přiděleno dostatek (navýšeno na cca 640 MB vyhrazené). Nisméně chování a management paměti pro danou sadu operací silně pčipomíná chování Wordu 97 při zpracování delších dokumentů. Rozložení textu na straně, není generováno dopočtem na základě chartakteristik, ale zdá se na základě vykreslení.

Algorytmus si pravděpodobně nehlídá zda a jak doběhlo vykreslení/přestránkování. Vznikají nesmysly typu prázdný sloupec, pro oddíl s více sloupci a nastaveným rovnoměrným rozložením, případně několik prázdných stran na nichž nebyl obsah z vložených dokumentů dogenerován (špatně napsaná paralelizace vygenerování stran z hlavního dokumentu?).

Silně mi to zavání tím, že generování stran, nikoliv jejich vykreslení, ale přímo rozložení objektů (tabulek, obrázků, sekcí), je provázáno přímo s grafickou knihovnou, což je zbytečný kotrmelec, pokud mám paraketry objektů, včetně valstností fontu definovány a známy předem.

Pokud je to skutečně takto hloupě provázáno s GL tak by mělo být při použití AOO sice lepší, ale neřešilo by to vlastní problém.
[/Edit1]

#6 Re: Writer » Záhadné zalamování tabulek » 12. 8. 2009 07:58:16

J8 začínám mít podezření, že se jedná o konkrétní chybu v xml kódu konkrétních tabulek. Protože chyba se opakuje stále u těch samých tabulek. Navíc většina jich nenídelší než jeden sloupec, ale má délku cca sedmi-osmi řádků textu. Takže mám podezření, že tam časem došlo k nějaké korupci xml, které OO z pochopitelných důvodů nedokáže restaurovat a dělá to tuhle chybu.

#7 Writer » Záhadné zalamování tabulek » 11. 8. 2009 15:47:52

majtas.d
Odpovědí: 6

Dobrý den, mám následující problém. (Open office 3.1, na WinXp sp3)
Mám delší blok textu okolo 120 stran o cca deseti sekcích. Sekce mají dva sloupce. Na konci určitých kapitol mám vložené tabulky, které občas vyjdou nešikovně na zalomení sloupce/stránky, takže začínají v jednom sloupci a pokračují v dalším.

V některých situacích mi dochází k tomu že se mi tabulka automaticky (zapomněl jsem poznamenat že tabulky nechám zalamovat automaticky OpenOfficem, mezery mezi odstavci a odsazení řeším přes nastavení vlastností odstavce potažmo přes šablonování stylů) zalomí ne na konci sloupce jak by jeden předpokládal, až kus dál, takže vzniká "díra v tabulce". Zbytek sloupce na stránce je bílé místo a tabulka vesele pokračuje v následujícím sloupci jako by se nechumelilo.
Děje se tak co jsem vypozoroval vždy v pravém sloupci a pokračuje na následující straně, k zalomení dochází vždy na konci prvního řádku polí ("okýnek") tabulky. Tabulka je jinak naprosto navazující a při posunu šipkou dolu poskočí kurzor ochotně na následující řádek níže, tedy na novou stránku. Problém se přenáší i při exportu do pdf, příkaz aktualiyuj vše nepřináší žádné výsledky.

Jediný prostředek kterým to umím momentálně obejít je uložit, ukončit OO a znovu načíst soubor, což je dosti na pytel a nešikovné. Nevím jestli je to nějaká moje chyba mezi klávesnicí a židlí a nebo nějaký bug v OO 3.1

Díky za radu.

#9 Writer » Mezera mezi předložkou a slovem » 20. 1. 2009 10:46:32

majtas.d
Odpovědí: 2

Narazil jsem na následující problém, při psaní textu v OO (bez ohledu na verzi) nerozlišuje OO.Writer mezi mezerou oddělující dvě slova a mezi mezerou oddělující slovo a předložku. Na rozdíl od MS officu který toto umí. V České typografii je ale pochopitelně nepřípustné aby se na konci řádky vyskytovala samostatná předložka bez k sobe vázaného slova.
Pochopitelně se daný problém dá řešit ručně, jenže to není ve své podstatě řešení ale obezlička. Zajímalo by mne jestli se dá někde v nastavení zadat že mezera mezi předložkou a následujícícm slovem k němuž se váže je automaticky mezera nezlomitelná (tj. tvrdá). Dalo by se to asi obejít vytvořením slovníku předložek (pokud už v balíčkách češtiny něco podobnéo neexistuje) a automatickou záměnou předložka_mezera_slovo za předložka_tvrdá mezera_slovo.
Existuje něco takového? Protože je naprosto zbytečné vytvářet duplicitně nějaké seznamy a slovníky znovu pokud už je někdo náhodou nevytvořil.

Děkuji za radu.

Zápatí

Používáme FluxBB