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

#1 31. 10. 2019 19:11:07

AdamB84
Člen
Registrace: 31. 10. 2019
Příspěvků: 2

Jak importovat text z calcu do writeru a zároveň ho naformátovat

Ahoj,

potřeboval bych dostat velké množství dat z Calcu do Writeru tak, aby se pro každý řádek z calcu (o 2 sloupcích dat) ve writeru vytvořila tabulka o 2 sloupcích (určitým způsobem naformátovaná) pro každý řádek zvlášť. Nenacházím řešení a zároveň nechci dělat přes tisíc řádků ručně smile.

Offline

#2 31. 10. 2019 20:41:43

kabi
Člen
Registrace: 1. 6. 2017
Příspěvků: 137

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

nedovedu si představit, co myslíte tím "zároveň ho naformátovat" a jak to formátování má vypadat. Pokud ten obsah máte naformátovan už v Calcu, asi nejjednodušší je vložit ve Writeru prázdnou tabulku s potřebným počtem sloupců a řádků (raději více), pak v Calcu ta data označit a zkopírovat, a do připravené tabulky vložit. Formátování (alespoň některé) by se mělo přenést.

Offline

#3 31. 10. 2019 20:45:19

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Tohle lze asi jen makrem. Nicméně je nutné vědět jak si to představujete. To znamená spíš ukázku nebo alespoň vysvětlení ve smyslu : 1. sloupec česky - 2. sloupec anglicky, nebo něco podobného. Určitě máte konkrétní představu což lze dovodit z tohoto :

AdamB84 napsal(a)

potřeboval bych dostat velké množství dat z Calcu do Writeru tak, aby se pro každý řádek z calcu (o 2 sloupcích dat) ve writeru vytvořila tabulka o 2 sloupcích (určitým způsobem naformátovaná) pro každý řádek zvlášť.

    To znamená pro každý jeden řádek Calcu samostatnou tabulku se dvěma sloupci - ale se záhlavím (nadpisem) - nebo bez? Co mezi tabulkami? - Nějaké pořadové číslo či heslo a nebo něco jiného - třeba specifikace nějaké podmnožiny ap.?


    Když jde o tisíce řádků tak se jedná o tisíce tabulek. Mají mít nějaký formát nebo alespoň nějakou specifickou úpravu? - Ve Writer se standardně uvažuje o fontu typ 12 bodů. Tisíce tabulek může být velice objemný soubor a měl by mít nějakou strukturu - tak aby se dal udělat například rejstřík a podobně. Dají se očekávat nějaké podmnožiny "zralé" na kapitoly?


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#4 1. 11. 2019 11:07:16

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Rozhodně to chce ukázku jak vstupního sešitu tak výsledného dokumentu. Jestli třeba v dokumentu potřebujete jeden řádek tučně, druhý kurzívou, třetí barevně atd. tak to je pro makro ještě celkem jednoduché.
Kdybyste však potřeboval částečné formáty řetězců (např. pouze jedno konkrétní slovo v řádku tučně, jiné jinak atd.), tak už je to složitější. No a nejtěžší je části řetězců správně naformátovat když části pro formáty jsou dané regulárními výrazy. 
Provedení toho částečného formátování může být při objemném souboru také dost pomalé, takže i na pracovní stanici to klidně může zabrat několik desítek minut (ale i hodin), na pomalejším stroji to bude nejspíš v mnoha hodinách. Dá se to o něco zrychlit když se to dělá po částech v nějakém tempu, ale jak mají zpracovávané soubory několik mb, skutečně to může být až i nečekaně náročné. 

Takže si chce dopředu spíše dobře promyslet co s tím skutečně chcete udělat a připravit si i nějakou mnohem menší testovací ukázku kde bude možno otestovat všechny potřebné varianty - než aby se to celé poněkolikáté zase pustilo přes noc a zase v tom výsledku ráno byly nějaké chyby :-).

Offline

#5 1. 11. 2019 16:44:11

AdamB84
Člen
Registrace: 31. 10. 2019
Příspěvků: 2

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Nepotřebuju žádné extra formátování. Potřebuju z tabulky o 3 sloupcích udělat toto:

https://www.uschovna.cz/zasilka/RY9NC6779ED922Z7-74M/

, kde "DTK" jsou *data z prvního sloupce*, horní řádek z obrázku je string s číslem, které se neustále zvyšuje o 1 + ". " + *data z druhého sloupce* a spodní řádek je " - " + *data z třetího sloupce*. A každý další řádek z tabulky je zpracován jako další tabulka.

Offline

#6 1. 11. 2019 18:00:02

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Není problém. Jenom původně jste psal o dvou sloupcích a nyní vidím že se jedná o 3 sloupce. Ten první je podle všeho uveden v prvním sloupci který slučuje dva řádky jako "DTK".
    Podle toho co píšete se v prvním řádku druhého sloupce objevuje číselná řada kterou ale musím vytvořit nebo je již obsažena?


PS : Soudím, že první sloupec je sloupcem "A", druhý sloupec "B" a třetí sloupec "C" - samozřejmě v Calcu a na Listu1. Makro se bude spouštět z Calcu ale je možné vytvořit spuštění z Writeru. Číslování přidám - smazat to půjde vždy (pokud by to bylo řešeno v rámci Calcu a sloupce "B" - což je velice pravděpodobné).


Nevidím upřesnění velikosti písma - ponechám font 12 (Calc implicitně používá 10). Může to být i fatální - velikost rozhoduje o počtu stránek. Pokud by to Writer neuvezl budeme muset rozdělit na více souborů. To ale ukáže až Vaše zkušenost.

Editoval neutr (1. 11. 2019 18:40:43)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#7 2. 11. 2019 11:17:00

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

neutr napsal(a)

ponechám font 12 (Calc implicitně používá 10)

.
Možná by bylo lepší tam nedávat natvrdo vlastnosti textu (velikost fontu 12 apod.) ale udělat pro ty buňky nějaký styl, bylo by to pohodlnější i pro případnou pozdější editaci těch tabulek.
Já se k tomu přes víkend nedostanu, možná až v pondělí, ještě nevím

Offline

#8 2. 11. 2019 19:34:16

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Otestujte verze1. Musíte mít zapnutá makra. Tedy povolení střední úrovně zabezpečení a důveryhodnou složku. Vytvořeno pro Libre Office.


     Soubor je vytvořen pro 5000 řádků (tabulek). Makro měří čas vytvoření - nic moc asi 20 minut na 5 tisíc tabulek. Použítí : Vezměte svoje data a vložte místo simulovaných dat. Spusťte nabídku "OVLÁDÁNÍ" > TĚŽBA DAT Z CALCU. Snad je to co potřebujete. Nic jste neupřesnil mimo výstupu. Takže když to nebude vyhovovat upřesněte lépe - co se má změnit.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#9 4. 11. 2019 09:44:08

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Dostal jsem se k tomu včera k večeru, doladil dnes ráno. Zde je má ukázka https://uloz.to/file/RLtYneUfroYV/calc- … ru-kl1-ods. Též se spouští z menu OVLÁDÁNÍ. Je to rychlejší tím, že se to pustí v neviditelném okně, přičemž ve stavovém řádku Calcu se zobrazuje průběh zpracování (aktualizuje se po deseti tabulkách). Pro buňky v těch tabulkách jsou navíc vytvořené odstavcové styly TAB_dtk, TAB_otazka a TAB_odpoved, tudíž změnou stylu (F11) se dají snadno změnit vlastnosti písma ve všech tabulkách. Tabulky také mají šedý rámeček jako v dané ukázce.

Když jsem testoval rychlost, tak neutrova ukázka mi proběhla za 12m:19s. Má ukázka s neutrovými daty (5000 řádků) za 4:01. Těch mých 1200 řádků mi to ztabulkovalo za 13 vteřin.

Neutr: jelikož jste zamkl to makro tak jsem se na to nemohl mrknout, ale jak prosím děláte to neustálé viditelné vykreslování nového obsahu (tedy že se vám dokument pořád posunuje na každou nově přidanou tabulku)? Skáčete po přidání tabulky a prázdného řádku s viditelným kurzorem na konec dokumentu? - viditelnyKurzor.goToEnd(false)

Offline

#10 4. 11. 2019 13:37:32

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

pro kamlan:
Na Váš dotaz odpovím jednoduše - ano.


     Já jsem tomu dal asi podstatně víc času, ale sledoval jsem různé systémy. Když jsem se v sobotu po obědě nedočkal upřesnění od autora udělal jsem to nejobyčejnější které žádné extra úpravy a optimalizaci neobsahuje. Mám zkušenost, že když autor komunikuje sporadicky, nebo vůbec - nemá cenu se jeho potřebou zabývat. Ve většině případů se ani neozve - to už máte také jistě ověřeno.


     Předpokládal bych, že to co bude skutečně v Calcu jako zdroj bude mít různě dlouhé řetězce. Někdy na více nežli 1 řádek. Když se zamyslím k čemu je to dobré - tak nejspíš k tisku štítků. V takovém případě lze očekávat že bude nutné eliminovat tabulky zalomené do dvou stránek.
     Pokud by šlo například o hřbety (třeba knih - odtud zkratka pochází "DeskTopPublishing") tak se dá čekat že kolonka "DTP" bude zarovnaná vertikálně - tedy kolmo k ostatním textům. Takže můj názor - autor nejspíš ani neví jak spustit makro - dělám zbytečnou práci. Pomůžu rád každému a nic nečekám, ale tenhle modus operandi převažuje. Pokud mne na tom něco zajímá, tak pouze možnosti různých řešení. Další záležitostí by byla optimalizace - pokud by taková práce k něčemu byla dobrá.


     Už jsem to psal. Zabýval jsem se možností vygenerovat systém tak jak jsem udělal, ale také systém kdy se spustí makro z Writeru a Calc se zavře. Jednoduše se do nového Writer(u) nahraje makro a předá se mu array s daty, předá se mu řízení a Calc se zavře. Ve finále je možné i makro smazat nebo z toho ".odt" udělat PDF.
     Prakticky bude zájem o jiný postup:
Z nadřazených maker spustit přímo Writer a tahat data z databáze - tou může být i Calc v registrované podobně, nebo tak jak je uložen. Pokud je to dáno tak jak je specifikováno zadání - bude se jednat o jednorázovou záležitost. Zde pak asi nehraje roli ani rychlost a podle všeho ani forma tabulek jako taková. Ovšem velikost písma bude důležitá v případě že se jedná skutečně o hřbet knih – čím větší tím lepší.
     V případě že se budou tisknout "hřbety" na samolepky je možné sestříhat i původně rozdělené tabulky. Původně jsem udělal tabulky bez mezi řádku, ale to by se špatně stříhalo. Samolepky jsou drahé takže bych si tipnul, že výstupní soubor bude upraven ve formátu stránky tak aby byl prostřih co nejmenší. Autor si také asi nechává pro sebe kolik řádků skutečně potřebuje.
     Neřešil jsem to a nechal na pokus - omyl řešení. Tedy spíš "spadne - nespadne". Stačí aby upravil počet řádků. Vadilo by mu sice vestavěné číslování - ale to může být řešeno jako lokální pořadí v jednotlivém sešitě. Za ním může být z Calcu skutečné absolutní pořadí. Spoléhám však na jeho tvrzení že jde o "přes tisíc řádků" - tedy méně nežli dva tisíce.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#11 4. 11. 2019 21:21:26

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Neutr: Spouštět to z Writeru jak jste psal mi přišlo spíše nešikovný, neb uživatel by beztak musel nějak zadat ten soubor Calcu s daty, pro což by asi nejjednodušší bylo otevřít mu dialog s výběrem souboru, ale to mi přišlo jako již zbytečně uživatelsky otravný a zesložiťující. Byť jak to předávání řízení popisujete tak to zní zajímavě, ale neumím si nějak předtavit, že by to v nějakém takovém případě skutečně bylo víc přínosný než složitější a pracnější. Ale vy to třeba využijete i jinde a alespoň už s tím tedy máte zkušenosti :-).


Já nad tou mou ukázkou strávil asi 5 hodin, ale to díky tomu že jsem různě hledal a testoval a vymýšlel jak nastavit ty vlastnosti tabulky. V rámci svého vyvíjeného superbastlu jsem se na to vkládání a formátování tabulek makrem tak jako tak chystal, tudíž když se to vyskytlo, tak jsem rád, že jsem to dal dohromady. Ono třeba na to nastavování barvy rámečků přes ty rodičovské elementy jsem si kdysi musel přijít sám, skutečně jsem to nikde když jsem to asi před dvěma roky potřeboval nenašel. Teď mi dala zabrat celá tabulka, neb ta se musí nastavit ještě o rodiče výš. Ta kontrola na 2000 řádků vznikla tak, že když jsem kopíroval ta vaše data, tak jsem najel myší na písmeno A a přetáhl ji přes B na sloupec C, tudíž se označily tři sloupce; pak Ctrl+V které trvalo nějak nezvykle déle a když jsem to pustil, tak to bylo nějak hodně pomalý -> a pak jsem zjistil že to nakopírovalo do všech řádků který Calc umožňuje. Takže pak jsem tam dal tu kontrolu :-). 


Poslední dobou se mi ohledně maker ale občas stává, že basic-bibli A. Pitonyaka dochází (i došel) dech a na webu také k tomu co bych k makrům potřeboval třeba nic, nebo třeba něco co musím všelijak upravit a doladit, aby to šlo použít třeba komfortněji. Takže se chystám začít vytvářet nějaký vlastní soubor s makry alá A. Pitonyak, ale s pokročilejšími možnostmi maker a optimalizovanými. Někdy je fakt hroznej opruz hledat nějaký věci k makrům a najít víc ukázek na několika webech/fórech a zjistit, že autoři to mají na jedno brdo, třeba nepraktické či s chybami nebo zbytečně složité - s čímž se český koumák rozhodně nemůže spokojit :-). Mít však různý spolehlivý řešení daný dohromady podobně jak to je v Andrewově knize je fakt super.


K čemu ty tabulky vlastně autor chce mě vůbec nenapadalo a vaše vysvětlení zní docela pravděpodobně (dnes mě napadly jakési vystřižené kartičky pro nějakou soutěž třeba pro děti). Ale zarazilo mě, že i přes jasnou výzvu dal autor prostě jen drobnou ukázku výstupu (ve které bylo nejisté dtp a zatajil i ony otázky a odpovědi - škoda, mohl jsem se možná něco málo dozvědět, lorem ipsum mě fakt nebaví, přežloutenkovaný oř vyúpěvší nějaké ty nostalgicko-kolektivizační trylky bývá lepší). Já po tomhle příkladu dospěl k závěru, že pokud autor příspěvku v podstatě nekomunikuje či komunikuje blbě, tak se mu skutečně dále nemá cenu věnovat. Kdyby byla jasná ukázka i těch vstupních dat, tak se nejspíš dala lépe udělat i nastavení toho sloupce dtp.

Nicméně je to fórum a nikoliv řešení pro-jednoho, takže i když nejspíš nedojde na zápis VYŘEŠENO, tak je možné, že někomu vytvořené ukázky či části z nich někdy pomohou. Ono i těch vašich 5000 tisíc řádků na různé testování vůbec není k zahození, ty čtyřpísmenné kombinace vypadají unikátní (neopakující se) :-).

Offline

#12 5. 11. 2019 07:47:24

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Pro kamlan :
     Uvádíte, že Vám připadá nešikovné spouštět makro z Writeru. To je dáno jenom tím, že ve Writer se dá udělat tabulka mnohem lépe a rychleji nežli v (z) Calcu. Calc svoje tabulky má, takže cizí tabulky nepotřebuje až na detaily kdy se používají například v dialogu.
     Testoval jsem nahrávané tabulky. Makro je mnohem rychlejší ale musí se pouštět právě z Writeru. Vy jste ve svém řešení použil specifikované parametry tabulky. Při tom správně uvádíte, že je to typ objektu který má svého rodiče. Správným řešením by bylo nastavení parametrů pro objekt vlastní tabulky a tu potom pouze replikovat. To je technologie která se v Basicu moc nepoužívá – deklarovat objekt jako „TYPE". Potom se mění pouze název (inkrementací čísla) a obsah řádků. Vy ale vytváříte vždy novou tabulku stejně jako tu první. Při tom musíte nastavit plno parametrů.


     Můj kód je asi poloviční i když pro tabulky používám podobný postup. Abych nemusel nastavovat parametry pro text použil jsem tabulku se třemi řádky. Ten první je nadpis centrovaný a navíc tučný ze standardního implicitního objektu. Já jsem nic nepřepisoval – udělal jsem tabulku a smazal jsem první řádek. Následně sloučil první sloupec, dal mu šířku a nakrmil to z array. Skutečně jsem dodělával dodatečně ten řádek mezi tabulkami.
     Systém takový že nejprve načte array pro přenos dat (primitivně – trvá to pár vteřin). Následně tuto array předá makru které vytvoří Writer. Opakování tabulky je dáno jednoduše cyklem For – next. Je to opravdu sešité hrubým stehem. Takové prasárny zamykám už jen proto abych zakryl ty postupy. Navíc to nemusím popisovat - popisování mne dost štve. (tedy někdy zamykám i z jiných důvodů ale tohle není ten případ). Filozofii jsem popsal ale autor ani nežádal nic takového z čeho by chtěl vycházet. Takže řešení je jak stojí a leží – co autor chtěl – dostal i když měl asi jiné představy.


     Možná si představoval něco jako úpravu v Calcu která se vyvede do orámovaných a proložených tabulek. Ty se pak naráz vloží do Writer. To by celkem šlo dobře v podobě exportu do PDF i bez maker. Ale úprava tisícovky řádků je náročná zejména pro málo zkušeného uživatele. Než bych popsal postup jak proložit vzorcem řádky, vytvořit binární řadou vedle ve sloupcích formát tabulky s načtením obsahu (kopírováním 1 > 2 > 4 > 8 > 16 >> … >>1024 > 2042) a následným exportem tak jsem navrhl makro – kde také nemusím nic vysvětlovat nebo jen minimum. (A nebo jednorázově přímo tabulku vytvořit z ostrých dat které by autor musel poslat.)
    Výše popsaný postup patří spíš mezi exotické postupy které vyžadují znalost klávesových zkratek a také vychytávek typu „proložení" řádků. Pochybuji že by stačilo několik vět. Nejspíš bych to musel zdokumentovat jako návod nebo jako prezentační makro. To patří už do redaktorského zpracování jako „TIP" - konkrétně jak co udělat. Dají se prokládat řádky i sloupce jak v pravidelném rozložení tak v nepravidelném. Konkrétně například oddělit data nestejně velkých sloupců tak aby se například vytvořil scházející řádek (prázdný), nebo naopak eliminovat prázdné řádky tak aby byly počátky v konstantním intervalu nebo jen s konstantní mezerou (prázdným řádkem). Viděl jsem kdysi i nějaké rozšíření pro takovou potřebu ale velice omezené.


     Na jeden takový „TIP" narážíte ve svém příspěvku. Je to zase jenom vychytávka. Jde o vzorec CHAR(RANDBETWEEN(65;95)) & CHAR(RANDBETWEEN(65;95)) & CHAR(RANDBETWEEN(65;95)) & CHAR(RANDBETWEEN(65;95)). Popřípadě něco fixního před nebo za. Dělám tak často náhrady za jména a podobně. Původně jsem tyto náhrady stavěl do podobny Base64 ale pro většinu případů je to zbytečné. Velká písmena začínají CHAR(65) a je jich 28 (ASCII 7 bit). Malá písmena jsou o 32 větší takže A= Char(65) malé a = Char(97). Logicky jde o náhodná čísla cca 30^4 takže opakování čtveřice je nepravděpodobné. Na konci se jen sloupec načte do paměti a vloží už jen jako text. Těch 3x 5 tisíc výrazů jsem dělal nejvýš 3 minuty ale spíš méně. Na to se ani makro nehodí – postavit ho trvá déle a pro jednorázové použití je to zbytečné.


     Je celkem chvályhodné že máte zájem udělat něco pro ostatní. To co uvádíte o Pythoniakově „bibli" je pravda. On sleduje prakticky jedinou větev ukázky v každé kapitole takže nejde ani tak o ucelenou práci se všemi možnými případy. Zase se snaží konkrétní případ popsat zevrubně a tím motivovat. Je to jakási síť příkladů na které navíc rád navazuje i mezi kapitolami.
     Ale i když to vypadá nedostatečně je to velice rozsáhlé. Dělá to už hodně dlouho a stále jen upravuje to co se od doby poslední úpravy změnilo. Mimo toho to pomáhá upravit celkem široká komunita. Na to jediný člověk opravdu nemá. Tedy sepsat snad ano, ale posléze kontrolovat funkčnost a popřípadě opravit – to je nekonečná práce.


     Já jsem udělal jen určitou kapitolu (respektive kapitoly) které nechávám uležet abych se na ně podíval jinýma očima. Jedná se o Writer a jeho „pole". To ale navazuje například na formuláře a nebo na databáze. Takže jak se znám – vše překopu ještě nejméně 2x. Už třeba vím, že nemohu Pythoniaka stopovat do hloubky a musím se obejít bez některých detailů – respektive bez vysvětlení proč to tak je.


     Když byste si troufl udělat například seriál o programování nebo formu manuálu tak klobouk dolů. Podobných pokusů je na tomto portále více ale žádný nebyl úplně dotažen. Snad nejlepší seriál je od Dana Sedláčka i když obsahuje chyby dané vývojem.


     Kdysi dávno tady byla možnost jek něco podobného udělat tak aby to bylo pro uživatele tohoto portálu. Byla to Wiki kde se slibně začalo – ale záhy se skončilo. Nechce se mi dělat návody jako rozšíření které stále otravuje s aktualizací vždy když vyjde nová verze LO a podobně. Náš portál je celkem dost utlačovaný zejména po stránce finanční. Autoři kteří byli specializovaní například na Base, nebo Writer a podobně prostě přestali psát. Například Dan Sedláček je stále uváděný jako moderátor ale byl zde naposledy 23. 5. 2014 16:14:23 .
     To souviselo nejvíc asi  s ing. Pastierikem který dělal velmi dobrou práci. Plno lidí zanevřelo na LO dík separatizmu a já osobně kritizuji „firemní kulturu". U nás není jediný člověk oprávněný oficiálně školit nebo zavádět LO do praxe. Nejdříve se musí prokázat znalosti a praxe právě z oblastí které nikdo bez požehnání Document Foundation dělat nemůže. Ano stačí se zabývat on line kurzem v angličtině ale musíte mít už „firemní zásluhy" jako například opičárny kolem podstatných věcí jako je grafika nebo být známým protagonistou – kterého „komunita zná" - samozřejmě ta komunita která se schází po světě a žvaní o migracích nebo výhodách LO. Potom snad dostanete oprávnění certifikovaného školitele nebo jiného firemního potentáta. Já mám dojem že jde spíš o to nekonkurovat MSO dokud to velký Bill nedovolí.


     Zase celkem nepochybuji, že se „invaze" LO soustředí na komerční firmy typu Collabora které se věnují asi jen specializovaným sektorům. Nějaký Kamil Landa určitě nemá šanci projít sítem a nabídnout některé firmě nebo instituci svoje služby. Prostě oprávněný nikdo není a jestli bude tak nejspíš firma. Zasloužilý protagonista musí umět nejdříve panáčkovat a dupat ve firemním rytmu. Je celkem jedno co umí nebo spíš neumí.
     Víte kolik je vynikajících rozšíření která už nejsou k dispozici i když většinou fungují nebo stačí malá úprava? Opravdu mnoho ale podívejte se jak lidé shánějí rozšíření od pana Pastierika nebo od Tomáše Bílka. Portál nemá ani pořádně na výplaty a jak se zjistilo nešlo ani zaplatit nějakou darovací částku. To je snad opraveno ale ukazuje to na plno věcí. Nevím jak to bylo s platební bránou ale vše je směrováno na LibreOffice. Při tom dodnes jsou všechny důležité věci stále pod palcem Apache Open Office. Bez zdrojů z portálu AOO by nešlo ani programovat v basicu a Libre umí nejvýše roubovat Pythonem. Zato umí akceptovat VBA. Všechno je postavené na hlavu.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#13 5. 11. 2019 18:27:44

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Neutr: Prosím zveřejnil byste váš výtvor nezaheslovaný nebo alespoň kód na to vkládání tabulek?

neutr napsal(a)

Správným řešením by bylo nastavení parametrů pro objekt vlastní tabulky a tu potom pouze replikovat. To je technologie která se v Basicu moc nepoužívá – deklarovat objekt jako „TYPE". Potom se mění pouze název (inkrementací čísla) a obsah řádků.

Vysvětlivky do kódu skutečně psát nemusíte, ani to nijak krášlit, tak jak to prostě je by mi to bohatě stačilo, já už se tím prohrabu -> jsem zvyklý se různě prodebugovávat doplňky a třeba je i modifikovat pro nějaké své specifické potřeby. Nebo pokud to přeci jen nechcete zveřejňovat tak bychom se domluvili na poslání třeba emailem? (Nechci nikde uveřejňovat svou adresu kvůli spamům, jsem rád že mi jich chodí dost málo, vy ji tu máte tak bych vám kdyžtak svůj email poslal na váš).

Dosud jsem netušil že je vlastně něco takového možné natož že by to mohlo značně zrychlit vytváření dokumentu :-). Já znám jako optimalizaci v podstatě spíše pouze osvědčené skrytí okna aby to nezpomalovalo vykreslování. Pro mé účely v rámci transkripčního doplňku by se mi to velmi hodilo, také v něm generuji tabulky a jakékoliv zrychlení je žádoucí. Navíc mám pocit, že takto to půjde urychlit nejen s tabulkami ale například i s rámci - a to by se mi opravdu hodilo -> jejich použití mám jako jednu z možností když jsou v transkripci dvě varianty -> tak tam vložím malý rámec a vepíši do něj ty možnosti nad sebe. No a někdy se v textu těch rámců vyskytne dost a zpomalení je opět znát.

Kdybych třeba v budoucnu psal nějaké makro a hodil by se ten váš postup do toho, tak bych tam ten postup již dal - ovšem přizpůsobený dané problematice a mnou popsaný, žádné tupé Ctrl+C/V hrubého stehu :-). Ono na takovouhle optimalizaci se člověk jen tak někde nedostane a věru bych ji moc rád viděl a dále ji používal.

Ale i s tím nejdřív si to načíst celé do pole je to dobré, fakt mě to v tak velkém použití nenapadlo. Byť tohle v Basicu umím, takže budu využívat. I ten nápad vložit tabulce o řádek víc a první smazat než jej měnit je dobrý, připomíná mi to trochu optimalizace v asembleru kdy třeba rychlejší je neskočit než skočit. Věru každá finta jak něco keplového jednoduše urychlit je žádoucí :-).


S nějakými starými doplňky co stále fungují nebo po nějaké malé úpravě mohou fungovat nějaké zkušenosti mám, rozšíření od T. Bílka či J. Pasteriaka jsou fakt vynikající. Ale i třeba menší jsou mnohdy dobré - takový španělský BasicIDETools (primárně pro AOO) si nemohu vynachválit -> to hromadné za/od-komentování řádků v Basic-editoru je prostě super, stejně jako možnost vkládat nějaký předdefinovaný kód. Pro to aby jeho verze 1.3 chodila i v Libre stačilo po rozzipování smáznout jeden tag z addons.xcu a bylo hotovo. Navíc když jsem koukal jak to dělá, tak je to jen v podstatě Ctrl+X, vyndat ze schránky do nějaké proměnné a tu zpracovat, dát jí znovu do schránky a Ctrl+V. Jen tenhle postup by byl na pěkný díl seriálu.

Nebo TemplateCharger, psalo mi to že nějaká fce je deprecated a stačilo najít v Libre SDK manuálu tu novou fci a nandat do ní tuším jeden parametr navíc a bylo hotovo.

Z Xraye jsem nedávno sosal jak se detekuje druh proměnné pomocí createUnoService("com.sun.star.reflection.CoreReflection"), ani nevím jak bych se tuhle detekci měl pokusit najít na webu, když jsem tu unoFci neznal.   


To vytváření určitého "manuálu" s makry chci dělat, neb to pro mě začíná být už i určitou nutností :-). Za asi 3 roky mám uložených pár stovek Basic návodů různě z webu a když něco hledám, tak už to začíná být docela problém se tím všelijak prohrabávat (přičemž gůglit by to bylo ještě horší, gůgl už ty výsledky vyhledávání fakt hodně změnil). A navíc si spoustu věcí beztak nezapamatuju, takže třeba i pro kopírování přes getTransferable si musím najít ten kousek kódu (i když jsou to asi jen 4 řádky) a CtrlCV.

Pro zajímavost: před pár měsíci jsem si nechával vytisknout samolepky na klávesnici (neb potřebuji cs, ar a en znaky) a v tiskárně mi obsluha říkala, že ty co mačkám nejčastěji se mi nejdříve ošoupou. Neošoupaly, přestalo lepit lepidlo jak mělo a začaly se pod prstem posunovat -> a byly to C a V, včera jsem je měnil, neb se mi na vytisknutou samolepící A4 vešly tři kopie :-).


Také mě napadlo že bych něco mohl psát právě i jako seriál na portál, ale nevím, jak moc je to na portálu zautomatizované, jestli by stačilo udělat to třeba v nějakém předdefinovaném odt (šabloně) a portál by si to sám převedl do potřebného html, nebo je to prostě složitější a musí se něco ručně zadávat. Zmiňoval jste Wiki, takže počítám že dost růčo. Já nemám internet a na větší onlajnování se můžu vykašlat, beztak mě to nebaví. Nicméně beztak by to mělo smysl kdyby toho bylo asi víc, nechtěl bych udělat jen pár nadšených prvních dílů a skončit. Ale i kdyby to nebylo na seriál, do odt/pdf (alá právě Pitonyak aspol.) to dávat chci. Ale trochu jinak než jak to je třeba právě v Pitonyakovi nebo v Malých makrech J. Pasteriaka. Nestojím o obsáhlé popisování spíše jednoduchých věcí a odmávnutí či až ignorování mnohem složitějších témat. Také není úplně vyhovující dávat tam hotové příklady na konkrétní zpracování dat, neboť nějaký potřebný základní algoritmus si pak z toho člověk musí vyseparovat, což také může být zbytečně pracné. 

Začal jsem ukazatelem průběhu s tlačítkem Zrušit, vše čistě vytvořené makrem -> neb ten využívám každou chvíli a nebavilo mě v Basicu dělat dialogové okno ručně. Takhle už je to jen o zavolání jedné fce :-). Ještě to však musím zapracovat právě do vznikajícího dokumentu. Dále se asi vrhnu na to co jsem zmínil o doplňku BasicIDETools a toho jak si vkládat vlastní kód do Basic editoru makrem, neboť třeba vkládaný kód pro různé Msgboxy též myslím dokáži o něco lépe :-).


Poslední dobou mi začíná připadat, že Libre se naprosto soustředí na to, že to je prostě "kancelářský balík" a takovým chce navždy být. Takže určitá "firemní struktura" se všemi negativy které to má v případě dalšího pokračování jakožto vyloženě kancelářské aplikace je od toho asi neoddělitelná, byť je to ke škodě. Ono nějaké angažování se v takové "struktuře" (a je jedno jestli firemní, armádní či institucionální) má pro člověka jednu značnou nevýhodu -> jedinci v tom se angažující si podle mě dávají za právo použít agresi když se jim to prostě hodí (a skutečně to tak dělají, ono i přehlasování a  musení se prostě podrobit výsledku hlasování je prostě agrese) -> a to naprosto koliduje s mou vírou. Ti co si dávají právo používat agresi (v jakékoliv formě) když se jim to prostě hodí, tak ať si sami jdou šlápnout na hrábě se hřebíkem, já se bez nich rád obejdu :-). Navíc Libre je spíše anglofonní projekt a hlubocí zainteresovanci v něm nepřemýšlí v češtině, takže vysvětlovat jim že něco je mnohem těžší či obsáhlejší než jak si usmysleli či jak se jim jeví, nebo že to fakt není tak naleštěný jak to mnohdy propagují, se setkává spíše s nárazem než s přijetím. Naučit se pro komunikaci pořádně anglicky beztak nepomáhá, rozhodně nebývá zvykem chápat tak do hloubky; občas mám u cizinců i pocit, že když se nad něčím začnou hluboce zamýšlet jak by se nad problematikou notně zamýšlel zdatný český kutil, tak se jim začne hroutit jejich svět. A co se zhrouceným tuňťou, že :-)? Takže mě tak napadá, že se v neodpovídající naleštěnosti nejspíš utvrzují a udržují schválně, doufaje že zhroucení se jim prostě nějak vyhne. Dle mně marný, ale důkaz pro to nemám :-).

Nicméně já mám Libre rád z jiného důvodu a to z důvodu toho, že relativně jednoduchým programováním se dá udělat spousta věcí, neboť Libre má prostě v podstatě velmi vyvinuté "vývojové prostředí" -> je fakt skvělý moci pro různý předělávky konfiguráku využít třeba buňky v Calcu, potřebně si je přeházet a zapsat zase do konfiguráku. Nebo fakt bych nechtěl vidět, co všechno bych se musel naučit naprogramovat, kdybych chtěl udělat třeba v C++ to co vytvářím v Libre -> třeba převést arabský text na křivky, rozkouskovat je na jednotlivá písmena, obarvit dle požadované transkripce určitá písmena - a udělat z toho pdf i html kód s původním textem, barevnou svg verzí textu a barevnou textovou transkripcí k tomu. V Libre na tom pracuji porůznu již asi 3 roky, kdybych to tu dobu programoval v něčem jiném, tak už bych asi nebyl schopen komunikovat s nikým z lidí, kolik těžkého programování bych pro to musel zvládnout - jestli bych to vůbec přežil :-). Ale jak píšete, bez portálu AOO (a hlavně jeho fóra) by to fakt nešlo. Tomu pythonu jsem nijak na chuť nepřišel a vlastně ani nevím, proč by měl být nějakou výhodou. V něčem někde možná jo, ale konkrétně fakt nevím v čem ani kde. A třeba z C++ už mě před lety dost bolela hlava a to už fakt ne, to ten Libre Basic je fakt mírumilovnej :-).

Offline

#14 5. 11. 2019 21:10:23

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Tak bych doporučil nejdříve něco k tomu "TYPE". Asi nejlepší je vzor od klasika který možná udělal pro programování víc nežli Pythoniak - B. Marcelly. Konkrétně se podívejte přibližně do 3/4 příspěvku zde Hledejte B. Marcelly


     Já mám v poznámkách kousek kódu který ani nevím kde jsem nabral - ale dá se to určitě dohledat. Měl bych najít i další ale myslím že si poradíte. Já už nevím ani pod čím to hledat.

Type FieldPairType
fieldName As String
fieldValue As String
End Type


Type FieldsListType
fieldCnt As Integer
fieldsAllocated As Integer
fields As Variant
End Type

Sub main
  Dim x(2) As New FieldPairType
  x(0).fieldName = "bob"
  x(0).fieldValue = "joe"
 
  Dim y As New FieldsListType
  y.fields = x()
 
  MsgBox y.fields(0).fieldName
 
  Dim a() As Variant
  a() = y.fields

  ReDim Preserve a(3)
  y.fields = a()
 
  MsgBox UBound( y.fields() )
  MsgBox y.fields(0).fieldName

End Sub

    Je to jiné použití ale když si uvědomíte že se takto dá vytvořit nový objekt respektive si naklonovat nějaký existující tak je to ono. Teď ještě makro které chodí v těch tabulkách. Měl jsem tam fůru zakomentovaných řádků které jsem smazal. Takhle to chodí. Když jsem zjistil že je už zase večer tak jsem to zašlápl jako vajgla, zamkl a poslal. Dá se to značně urychlit, ale přepadl mne pocit (jak vidno správný) že to není k ničemu.

Sub TezbaCalcu
Dim oSheet as object
Dim oCell As Object
Dim oCursor As Object
oDoc = ThisComponent
oSheet = ThisComponent.Sheets.getByIndex(0)
oCell = oSheet.GetCellbyPosition(0, 0)
oCursor = oSheet.createCursorByRange(oCell)
oCursor.GotoEndOfUsedArea(False)
LR = oCursor.RangeAddress.EndRow
sTimer = Timer()
Dim sVar(0 To 2,0 To LR) As variant
For i = 0 To LR
sVar(0,i) = oSheet.GetCellbyPosition(0, i).String
sVar(1,i) = oSheet.GetCellbyPosition(1, i).String
sVar(2,i) = oSheet.GetCellbyPosition(2, i).String
next i
WriterTable_CalcData(sVar, LR)
eTimer = Timer()-sTimer
MsgBox("Práce " & LR + 1 & " tabulek provedena za " & INT(eTimer/60) & " minut a " & eTimer MOD 60 & " sekund",64, "Konec práce")
End Sub

Sub WriterTable_CalcData(ByRef svar() as Variant, ByVal ER as long)									
	Dim oDoc									
  	Dim oTable									
  	Dim oCurs									
  	Dim oText									
  	Dim Dummy()									
  		oDoc = StarDesktop.loadComponentFromURL("private:factory/swriter", "_blank", 0, Dummy())
  		oVCursor = oDoc.getCurrentController().getViewCursor()								
  		oText = oDoc.getText()
  		oVCursor.gotoEnd(True)							
For i = 0 To ER 
sVar1 = svar(0,i)
sVar2 = i + 1 &". " & svar(1,i)
sVar3 = svar(2,i)
  		oTable = oDoc.createInstance("com.sun.star.text.TextTable")	
		oTextCursor = oText.createTextCursor()
		oText = oDoc.getText()															
		oVCursor.gotoEnd(True)															
		with oTextCursor															
			.CharHeight = 12														
		End With						
  			oTable.initialize(3, 2)							
  			oCurs = oDoc.getCurrentController().getViewCursor()							
  			oText.insertTextContent(oCurs, oTable, False)							
  			oTable.setDataArray(Array(Array("",""), Array("",""), Array("",""))
  			'------------------------------------------	
  			oRows = oTable.getRows() 
			oRows.removeByIndex(0,1)
			'------------------------------------------						
  		Dim oTableCur as Object								
  			oTableCur =oTable.createCursorByCellName("A1")							
  			oTableCur.goDown(1,True)							
			oTableCur.mergeRange()
			'------------------------------------------							
  		Dim oTblColSeps 							
  			oTblColSeps = oTable.TableColumnSeparators							
  			oTblColSeps(0).Position = 2000	
  			oTable.TableColumnSeparators = oTblColSeps
  			'------------------------------------------
  		Dim oCell0, oCell1, oCell2 							
    		oCell0 = oTable.getCellByPosition(0, 0)
    		oCell0.string = svar1
    		oCell1 = oTable.getCellByPosition(1, 0)
    		oCell1.string = sVar2
    		oCell2 = oTable.getCellByPosition(1, 1)
    		oCell2.string = sVar3
    		'------------------------------------------
'Tady jsem vymýšlel úpravu stránky tak aby se nezalamovaly tabulky to jsem ale nedotáhl a vykašlal se na to.
  Dim MyString as String															
  Dim oSlections																	
  Dim oSelCount																	
  Dim oSel																	
  Dim oRange   																	
	oSelections = oDoc.getCurrentSelection()																
    oSelCount = oSelections.getCount()																	
    If oSelCount > 1 then																	
    	oSelCount = oSelCount-1																
    End If
'Tady jsem dodatečně vkládal řádek																	
    For j = 0 To oSelCount - 1																	
		oSel = oSelections.getByIndex(j)															
    	oRange = oSel.getEnd()															
  		oInsetText = Chr$(13) & ""															
  		oRange.setString(oInsetText)															
  	next j
next i
End Sub	

    Tam kde jsem "slepoval" je zakomentovaná čára (bez komentáře) - což je ten "hrubý steh". V podstatě jen zprovozněný a neoptimalizovaný kód.

Editoval neutr (5. 11. 2019 21:11:00)


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#15 5. 11. 2019 23:31:06

lp.
Člen
Registrace: 24. 9. 2009
Příspěvků: 810

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Řekl bych, že vše je dávno hotovo. Například:

Příprava hromadné korespondence, štítků a obálek v LibreOffice

Offline

#16 7. 11. 2019 22:23:10

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

Ip.: Odkazovaný článek je perfektní a podařilo se mi do dokumentu vložit tabulku jako dle představ autora příspěvku a dát ten "tisk" - čili to vytvořilo dokument se všemi tabulkami. Příjemné je, že to Libre zpracuje docela rychle. Došlo však k jisté nevýhodě a to, že při tisku by to vytisklo každou tabulku na jednu stránku, tudíž spotřebovat na tom necelé tři balíky papíru (autor potřeboval přes 1000 tabulek) by rozhodně nebylo ono. Nicméně dá se to obejít docela snadno, já to zkusil přes html :-).

Výsledný dokument stačí dát uložit jako HTML, to pak otevřít ve Writeru a dát Zobrazit/ HTML zdroj. Objeví se html kód a v tom stačí vyhledat řádek který začíná na <table a v něm označit parametr style="page-break-before: always" (případně mi to někdy vytvořilo style="page-break-before: always; page-break-inside: avoid"), dát Ctrl+H a v nahrazujícím dialogu jen zmáčknout Nahradit vše. Nebo lze dát vyhledat jen to page-break-before: a nějak to zmršit, třeba to nahradit za ŘŘŘpage-break-before: -> když v html kódu je něco špatně tak to programy chytře ignorují :-) -> a zde jde o to se prostě zbavit toho zalamování tabulek na nové stránky jež je dáno oním parametrem.

Pak stačí zase dát Zobrazit/ HTML zdroj aby se to přeplo na vizuální zobrazení a poté přepnout Zobrazit/ Normální na klasické zobrazení a už to nebude rozestránkované :-).

Jistá nevýhoda převodu do html může být ale ta, že se může ztratit nějaké složitější formátování textu které se z odt do html prostě nepřevede.



neutr: To klonování objektů přes pole nefunguje. Redim preserve udělá kopii pole pro normální vlastnosti jako string, integer apod., ale pro části objektů zanechá v těch částech reference místo aby zkopíroval hodnoty. Stačí v tom kódu co jste uvedl změnit nějakou vlastnost a změní se to u obou objektů.

	Type FieldPairType
		fieldName As String
		fieldValue As String
	End Type
	
	Type FieldsListType
		fieldCnt As Integer
		fieldsAllocated As Integer
		fields As Variant
	End Type

Sub main3
  Dim x(2) As New FieldPairType
  x(0).fieldName = "bob"
  x(0).fieldValue = "joe"
 
  Dim y As New FieldsListType
  y.fields = x()
 
'  MsgBox y.fields(0).fieldName
 
  Dim a() As Variant
  a() = y.fields

  ReDim Preserve a(3)
  y.fields = a()
 
	MsgBox "x(0): " & x(0).fieldName & chr(13) & "y(0): " & y.fields(0).fieldName & chr(13) 'vypíše původní vlastnosti
	
	x(0).fieldName="jiny" 'změní vlastnosti jak pro x tak pro y
  MsgBox "x(0): " & x(0).fieldName & chr(13) & "y(0): " & y.fields(0).fieldName & chr(13) 'oba objekty jsou změněné
  
  	y.fields(0).fieldName="zase obě" 'i pro y to změní vlastnosti obou objektů
	MsgBox "x(0): " & x(0).fieldName & chr(13) & "y(0): " & y.fields(0).fieldName & chr(13) 'obě vlastnosti jsou změněné
End Sub

Pitonyak má pro kopírování objektů jednoduchou ukázku, jenže je v tom rozdíl že to vytváří přes CreateObject. To možná bude ten důvod, že při obyčejném rovnítku se udělá kopie takto vytvořeného objektu.

Sub ExampleCopyAsValue
	Dim aProp1
	Dim aProp2
	aProp1 = CreateObject("com.sun.star.beans.PropertyValue")
	aProp1.Name = "Age" 'Set Name Property on one
	aProp1.Value = 27 'Set Value Property on one
	aProp2 = aProp1 'Make a copy -> zde se vytvoří kopie, převzalo to stejné vlastnosti, stačí si obě proměnné dát do Kukátka
	aProp2.Name = "Weight"'Set Name Property on two
	aProp2.Value = 97 'Set Value Property on two
	Print aProp1.Name, aProp2.Name 'Age Weight -> má to jiný vlastnosti, jde to vidět pěkně v Kukátku
End Sub

Jenže ta writerovská tabulka je pomocí CreateInstance a asi proto se prostě její polymorfizovatelný klon neudělá, neb to nemá jen vlastnosti ale jsou tam i různé metody, interface, listenery a služby (navíc některé jsou jen pro čtení), takže by jistě docházelo k různým konfliktům kdyby někdo dělal klony a měnil jen některé vlastnosti. Řekl bych, že velmi brzy by se našel nějaký filuta, který by zkusil něco jako oMachr=naklonuj(thisComponent) nebo ještě lépe oDrson=naklonuj(StarDesktop) :-).


Mně se povedlo udělat modifikovatelnou kopii objektu akorát když jsem natvrdo nastavil jeho konkrétní vlastnosti, taky jednoduše přes rovnítko ale fakt jednu vlastnost po druhý

	Type tVzor
		s$ i%
	End Type
Sub ukazkaKopieObjektu 'vytvoření kopie objektu
	dim o1 as new tVzor, o2 as variant
	o1.s="abc" : o1.i=123
	o2=kopie(o1)
	msgbox "o1: " & o1.s & o1.i & chr(13) & "o2: " & o2.s & o2.i
	o2.i=456
	msgbox "o1: " & o1.s & o1.i & chr(13) & "o2: " & o2.s & o2.i
End Sub

Function kopie(o as variant) as variant
	dim a as new tVzor
	a.s=o.s 'předat vlastnosti jednu po druhý
	a.i=o.i
	kopie=a
End Function


Nicméně velkou radost mám z metody setDataArray, o té jsem "netušil" (i když už jsem jí předtím viděl ale zapomněl na ní), ta zrychluje vyplňování tabulek výtečně, už jí využívám v Calcu když se snažím změnit rozkouskovaný datový soubor od vytvářeného fontu a donutit tak program FontForge udělat něco co vůbec neumí. Ještě to sice bude pár dní boj, ale snad se zadaří :-).


To EnumarableMap vůbec není špatné, neznal jsem to. Připomíná mi to trochu javascriptové asociační pole (tedy pole ve kterém jsou indexy řetězce -> např. pole["pozdrav1"]="ahoj";pole["pozdrav2"]="cau";). Já včera narazil na to, že normální array() má omezenou velikost, ale povedlo se mi to snad vyřešit takto:

Sub velkeArray 'zvětšování pole když nestačí
	dim oProps(0) as new com.sun.star.beans.PropertyValue 'do tohohle budu vkládat pole jedno po druhém když mi dojde potřebná velikost normálního array daná dále v iLimit
	dim i&, j&, iLimit& 'potřebný iLimit pro vyhovující velikost normálního array je asi nejlepší vždy odzkoušet na zpracovávaných datech
	iLimit=5 '16368 'tolikátý index mi pro :pole(iLimit) as string: ještě fungoval když jsem načítal řádek po řádku ze souboru jež měl 23 tis. řádků, při větším čísle se v každém dalším prvku objevil vždycky řádek první
	dim pA(iLimit) as string 'pomocné pole které budu využívat
	dim iKolik& 'kolikáté podpole v oProps budu vytvářet
	dim sNazev$
	sNazev="PODPOLE" 'prefix pro názvy jednotlivých podpolí v oProps
	iKolik=0 'kolik podpolí budu mít v oProps
	j=0 'počítadlo indexů pro pomocné pole
	for i=0 to 11 '12 'dvanáctka pro iLimit=5 vytvoří již 3 podpole
		pA(j)="hodnota" & i 'hodnota do pomocného pole
		if j=iLimit then 'jsem na limitu počtu indexů
			j=0
			oProps(iKolik).name=sNazev & iKolik : oProps(iKolik).value=pA() 'vložit do oProps již naplněné pomocné pole pod jménem PODPOLEčíslo
			redim pA(iLimit) 'vynulovat pomocné pole
			iKolik=iKolik+1
			redim preserve oProps(iKolik) as new com.sun.star.beans.PropertyValue 'přidat do oProps další podpole
		else
			j=j+1
		end if
	next i
	if j<>0 then 'když má zbylé pomocné pole méně prvků než iLimit tak ještě vytvoří podpole v oProps
		redim preserve pA(j-1) 'zkrátit pomocné pole na skutečný počet prvků
		oProps(iKolik).name=sNazev & iKolik : oProps(iKolik).value=pA() 'poslední podpole do oProps
	else
		redim preserve oProps(iKolik-1) 'když to vyšlo přesně na iLimit tak odstraní poslední prázdné podpole z oProps
	end if
	msgbox oProps(1).value(2) 'no a zde je nějaký prvek z toho vytvořeného multiPole
End Sub

Offline

#17 8. 11. 2019 08:21:24

neutr
Člen
Registrace: 8. 3. 2007
Příspěvků: 2,988

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

pro kamlan:

kamlan napsal(a)

Ip.: Odkazovaný článek je perfektní a podařilo se mi do dokumentu vložit tabulku jako dle představ autora příspěvku a dát ten "tisk" - čili to vytvořilo dokument se všemi tabulkami. Příjemné je, že to Libre zpracuje docela rychle. Došlo však k jisté nevýhodě a to, že při tisku by to vytisklo každou tabulku na jednu stránku, tudíž spotřebovat na tom necelé tři balíky papíru (autor potřeboval přes 1000 tabulek) by rozhodně nebylo ono. Nicméně dá se to obejít docela snadno, já to zkusil přes html :-).

Výsledný dokument stačí dát uložit jako HTML, to pak otevřít ve Writeru a dát Zobrazit/ HTML zdroj. Objeví se html kód a v tom stačí vyhledat řádek který začíná na <table a v něm označit parametr style="page-break-before: always" (případně mi to někdy vytvořilo style="page-break-before: always; page-break-inside: avoid"), dát Ctrl+H a v nahrazujícím dialogu jen zmáčknout Nahradit vše. Nebo lze dát vyhledat jen to page-break-before: a nějak to zmršit, třeba to nahradit za ŘŘŘpage-break-before: -> když v html kódu je něco špatně tak to programy chytře ignorují :-) -> a zde jde o to se prostě zbavit toho zalamování tabulek na nové stránky jež je dáno oním parametrem.

Pak stačí zase dát Zobrazit/ HTML zdroj aby se to přeplo na vizuální zobrazení a poté přepnout Zobrazit/ Normální na klasické zobrazení a už to nebude rozestránkované :-).

Jistá nevýhoda převodu do html může být ale ta, že se může ztratit nějaké složitější formátování textu které se z odt do html prostě nepřevede.

     Zajímavý komentář. Zejména ty popisované úpravy na vhodnou podobu podle zadání. Víte to se má jinak. "lp." toho moc nenapovídá a tak se zapoměl zmínit, že když si vyberete z volby SOUBOR > NOVÝ > ŠTÍTKY tak si můžete na kartě MOŽNOSTI nastavit více štítků na stránce a tyto synchronizovat. Není potřeba se drbat pravou rukou za levým uchem přestože je to možné.
     Takové řešení je dobré ale musíme mít jistotu, že se tabulky budou držet ve stejné výšce, respektive šířce. Jinak se budou různě nafukovat podle obsahu a efekt je pryč. Právě proto jsem hledal řešení které by umožnilo tisk nerozdělených tabulek - ale vzdal jsem to. Štítky jsou také objekty a o to by se muselo více programovat. Z hlavy bych to nedal a musel bych pitvat zdroje.

kamlan napsal(a)

neutr: To klonování objektů přes pole nefunguje. Redim preserve udělá kopii pole pro normální vlastnosti jako string, integer apod., ale pro části objektů zanechá v těch částech reference místo aby zkopíroval hodnoty. Stačí v tom kódu co jste uvedl změnit nějakou vlastnost a změní se to u obou objektů.

     Ale v tom je to řešení právě výhodné. Já jenom nevím proč citujete ReDim Preserve. Toto je příkaz který značí změnu parametrů se zachováním stávajících. To co je v kódu vedeno ukazuje na další proměnnou která v ukázce není definovaná. Ukazuje jak se dynamicky přidávají například property - tedy třeba celé array.
     Můžete přeTYPovat array i pouhým "ReDim" - ale podle druhu přetypování se projeví například prázdná array. Přetypování může znamenat jak zvětšení tak zmenšení pole, nebo třeba přetypování z numerické na string, nebo variant. Jde také o tz. "pole polí" což je nejčastější právě u property objektů. Při tom totiž základní array nese "y" jednorozměrných array (x) a tato nemusí být stejné ve smyslu velikosti ani typu. Samozřejmě array může být i mnohorozměrná. Setkáme se asi nejčastěji s 2D, ale existují i vyšší řády - 3D, 4D.... Takže nějak nechápu Váš komentář jako celek. Originál objekty se tvoří jako instance tříd v Java. To jsou ale jak jistě víte knihovny DLL. TYP(ování) je dynamycká úprava a má dočasný charakter a ten rozdíl je zřejmý. Příkaz (nebo funkce - nevím) CreateObjekt je v podstatě klonování existujících objektů.
     To co jsem měl na mysli je skutečně dynamické provázání tabulky s odstavcem který končí prázdným řádkem. Celý "virtuálně myšleno" objekt je pak typem paragrafu (odstavce) a nikoliv tabulky i když by se asi muselo otestovat zda to má predikovaný efekt. Zabýval jsem se také funkcí která ale stále iteruje dokola parametry.
     Ještě více mne udivuje skutečnost že jste neznal výrazy setDataArray. Běžně se volá pomocí GetDataArray a vkládá (ukládá) SetDataArray. Jsou to typické případy práce v Calcu kde se načítají buď jako indexované pole, nebo pojmenované úseky. Já to používám také ale raději mám běžnou deklaraci a(x,y). Souvisí to s iteracemi v polích které jsou trošku nelogické. Mají ale výhodu že se načítají rychleji nežli pomocí jednotlivých buněk (tak jak jsem to udělal v těch tabulkách). Vývojové verze dělám "pomalé" a zrychluji až při optimalizaci a tak bych přešel z pomalejšího čtení na rychlejší - ale to je spíš můj zvyk nežli potřeba.


Moje e-mailová adresa
Pokud je Váš problém vyřešen, označte prosím svůj příspěvek za "VYŘEŠENÝ"
Zlepšíte orientaci při vyhledávání řešení JAK OZNAČIT TÉMA ZA VYŘEŠENÉ

Offline

#18 8. 11. 2019 20:32:30

kamlan
Člen
Registrace: 15. 9. 2016
Příspěvků: 115

Re: Jak importovat text z calcu do writeru a zároveň ho naformátovat

neutr: O Štítcích jsem vůbec netušil a musel bych se s nimi naučit, což by bylo na déle než ten postup přes html :-). Nicméně včera večer už jsem byl přetaženej a tak jsem se na třeba pokus o odstranění těch zalomení stránek makrem už nevzmohl, kdežto s html docela umím (vysvětleno dále). Dnes jsem byl úspěšnější, ukázkový spoubor zde https://uloz.to/file/UBpFCI4aH843/tabul … navodu-odt. Jinak makro z něj tady

Sub odstranitZalomeniStranekVtabulkach
	rem odstraní zalomení stránek která jsou dána nastavením vlastností tabulek
	rem v Tabulka/ Vlastnosti -> Tok textu/ Rozpojit
	dim oDoc, oTables, oTable, i%
	oDoc=thisComponent
	oTables=oDoc.TextTables
	for i=0 to oTables.count-1 'procházet tabulky
		oTable=oTables(i) 'tabulka
		rem tohle odstraní to zalomení stránek
		oTable.breakType=0 : oTable.pageDescName=""
	next i
End Sub

Při vkládání makrem pod tabulku možná ani není potřeba vkládat řádek, stačí nastavit spodní okraj tabulky

Sub tabulkaOdsazeniSpodku
	dim oDoc, otext, i%, oTable
	oDoc=StarDesktop.LoadComponentFromUrl("private:factory/swriter", "_blank", 0, array()) 'nový soubor Writeru jako neviditelný
	oText=oDoc.text
	for i=0 to 1
		oTable=oDoc.createInstance("com.sun.star.text.TextTable") 'vytvářená tabulka ve Writeru
		oTable.initialize(2,2) '2 řádky, 2 sloupce
		oText.insertTextContent(oText.getEnd(),oTable,false) 'vložit tabulku do dokumentu
		oTable.setDataArray(Array(Array("aa","bb"), Array("cc","dd"))
		oTable.bottomMargin=300 'mezera pod tabulkou
	next i
End Sub

Chtělo by to v těch námi vytvořených makrech případně i nastavit, aby se tabulka nerozdělovala přes stránky a sloupce, ale to už nyní dělat nebudu.


K tomu redim preserve.

neutr napsal(a)

To co je v kódu vedeno ukazuje na další proměnnou která v ukázce není definovaná. Ukazuje jak se dynamicky přidávají například property - tedy třeba celé array.

Jistě, pomocí redim preserve se dají dynamicky přidávat další proměnné, ale zmiňoval jste pod ukázkou "... respektive si naklonovat nějaký existující ..." a já myslel, že ta ukázku měla udělat i ono naklonování objektu s tím, že nově přidanému objektu se budou dát měnit vlastnosti aniž by to měnilo objekt vzorový - a to ta ukázka jak jsem ukázal neudělá -> přidá sice někam nějaký další prvek, ovšem při změně vlastností toho přidaného prvku se změní i vlastnosti vzorového prvku. Kdybych tam do toho x dal tu vytvořenou tabulku, a pak jí přidal tím postupem do y, tak při změně nějakého parametru v y by se mi to změnilo i v x, protože by to neudělalo modifikovatelný klon, ale pouze do dvou proměnných umístilo jedno a to samé, což by tedy měnilo stále jen první tabulku. Když jsou v tom poli jen jednoduché proměnné nafrkané tam z jiného pole, tak to redim preserve skutečně udělá klon těch jednoduchých proměnných.

Sub klon1 'naklonuje pole když jsou v něm jednoduché proměnné (tedy bez objektových struktur) (https://forum.openoffice.org/en/forum/viewtopic.php?f=21&t=93610)
	dim x(2), y(2)
	x=array("a","b","c")
	y=x 'tohle neudělá nezávislou kopii pole
	y(1)="Q"
	msgbox x(1) & chr(13) & y(1) 'došlo sice ke změně v y, ale také v původním x
	redim preserve y(ubound(y())) 'tohle už to pole osamostatní (udělá tedy modifikovatelný klon který již při změně vlastností nezmění vlastnosti v původním vzoru)
	y(1)="W"
	msgbox x(1) & chr(13) & y(1) 'došlo ke změně jen v y
End Sub

rem jenže 'osamostatnění' pole nefachá na objekty
	Type tVzor
		s$ i%
	End Type
Sub klon2neAne 'nevytvoření modifikovatelné kopie objektu přes redim preserve
	dim o1 as new tVzor, o2 as variant, x(2), y(2)
	o1.s="abc" : o1.i=123
	x(0)=o1 'dám objekt do pole
	y=x 'dám pole do druhého pole
	redim preserve y(2) 'zkusím fintu jako v proceduře klon1 o osamostatnění prvků pole
	o2=y(0) 'dám do druhého objektu rádoby osamostatněný prvek pole
	msgbox o1.s & o1.i & chr(13) & o2.s & o2.i 'o1 i o2 jsou stejné takže se to může jevit jako úspěšné zkopírování o1 do o2
	o2.i=456 'změna o2
	msgbox o1.s & o1.i & chr(13) & o2.s & o2.i 'o1 i o2 jsou opět stejné, takže o2 není klonem o1 ale jen redundantním o1
End Sub
kamlan napsal(a)

Stačí v tom kódu co jste uvedl změnit nějakou vlastnost a změní se to u obou objektů.

neutr napsal(a)

Ale v tom je to řešení právě výhodné

. Ale k čemu by mělo být výhodné mít ve dvou proměnných jedno a to samé? Nebo jinak, k čemu by mělo být výhodné mít duplicitní proměnné? Kdyby šlo o neblahý přístup typu samotných MS Windows "RAMky je přece dost!" tak jistě ano :-), ale jinak v tom smysl nějak nevidím. Možná jsem ale špatně pochopil vaše původní popsání. 

neutr napsal(a)

Správným řešením by bylo nastavení parametrů pro objekt vlastní tabulky a tu potom pouze replikovat.

Já si z tohoto vyvodil, že rychlejší by mohlo být udělat kopii proměnné oTable a ve smyčce for..next pak měnit pouze pár vlastností kopie namísto použitého vytváření pokaždé nové proměnné oTable=oDoc.createInstance("com.sun.star.text.TextTable") právě uvnitř for..next.


Jak jsme to udělali oba:

for ...
	oTable=oDoc.createInstance("com.sun.star.text.TextTable")
	...
	oText.insertTextContent(oCurs, oTable, False)
next

Jak jsem si myslel že jste to urychlení myslel :-)

oTable=oDoc.createInstance("com.sun.star.text.TextTable")
oKOPIE=kopieObjektu(oTable)
for ...
	oKOPIE.zmenNeco
	oText.insertTextContent(oCurs, oKOPIE, False)
next

No a na vytvoření toho modifikovatelného klonu(kopie) oKOPIE jsem si myslel že zobrazujete právě tu ukázku Type FieldPairType .... Ale možná jsem ten váš myšlený postup blbě pochopil, nevím.


Tu kopii proměnné oTable z oTable=CreateInstance(...) se mi prostě vytvořit nepodařilo a možná to prostě možné není, neboť sám program Libre (zřejmě soffice.exe či soffice.bin) dle některých jejích částí něco vykonává a jistě by docházelo ke kolizím, kdyby se udělal nezávislý klon a v jedné z těch dvou verzí došlo k nějaké změně. Jak by se pak Libre mělo zachovat? Otevřít pro tu jednu změněnou verzi třeba úplně nový Writer? Či prostě druhou z verzí ignorovat? Nebo se snad ptát uživatele: "hele jsou dvě programátorský možnosti, kterou z nich si vybereš?"


Jinak co jsem ještě zjistil tak masivnější nasazení redim preserve dokáže být docela pomalé, ale to spíš jen tak pro zajímavost když jsem načítal data aniž bych věděl předem kolik jich bude a používal pro každý další načtený údaj redim preserve.

sub ee 'pomalé redim preserve
	dim p(0), i%, a as date, a0 as date
	a0=now
	for i=0 to 10000 '10tis za 16 vteřin, 20tis již za 1:16
		p(i)="text" & i
		redim preserve p(i+1)
	next i
	a=now-a0
	msgbox CStr(timeSerial(Hour(a),Minute(a),Second(a)))
end sub

No a co se týká vícerozměrných polí, tak já zkusil do pole načíst textový soubor který měl 23tis. řádků a když jsem je dal zobrazit v Kukátku, tak mi to zobrazilo že jsou správně načtené jen do indexu 16368 a od 16369 že jen neustále načítán jen první řádek. To samé se mi dělo když jsem zkusil různé pole polí array(array(...), array(...), ...), vždycky to načetlo správně jen těch 16369 řádků a tak jsem si chybně myslel, že tedy array má nějakou omezenou velikost. Jenže ono to načtení do pole očividně funguje dobře, ale Kukátko nejspíš holt zobrazuje špatně https://uloz.to/file/aSiRi8hV4Otk/chyba-png. Tudíž mé nadlimitní multiPole byl vlastně zbytečný výtvor :-). No ale alespoň vím, že v Kukátku je tedy zásadní chyba. Xray tolik proměnných nevypíše, krátí výpis dlouhých polí asi na 2000 řádků.


Já si vzpomněl jak to bylo s mým setDataArray a getDataArray :-). Narazil jsem na to když jsem se učil getTransferable na konci článku https://www.openoffice.cz/doplnky/kopirovani-dat , ale jelikož jsem tehdy nedělal v Calcu a měl jsem ho navíc z mně neznámých důvodů v nelibosti, tak jsem to tehdy spíše hrubě odmávl s tím, že o tom "vím" a že kdybych to potřeboval, tak se k tomu holt někdy vrátím. To byla chyba :-). Dnes už Calc mám ve velké oblibě.


Co se týká mého programování, tak sice se tomu věnuji od dětství, ale od opuštění škol ryze svérázně amatérsky. Začal jsem před 30-ti lety jako dítko chodit ještě do socialistického Domu dětí a mládeže na kroužek programování a co možná dějiny (ne)chtěly -> mohu dokonce tvrdit, že pár týdnů nato spadl celý systém :-); avšak nevnímám, že bych se na pádu tehdejšího systému jakkoliv podílel :-). No pak jsem vystudoval keply na elektroprůmce - ale nebylo to moc pokrokový, třeba praktickou maturu jsem měl v roce 1999 z instalace starších verzí Ms-Dosu, kde jsem z 5-ti disket instaloval a různě konfiguroval systémy ms-dos 3.0, 5.0 a 6.22. Na VŠ do mě začali bušit objekty, jenže já tam tehdy pochopil akorát ukazatele a dynamický proměnný a objekty už na mě byly moc těžký -> možná i tím, že jsem je krom školy nikde v ničem nepotřeboval a nebavilo mě to. Možná i tím, že tehdy jsme se pořád učili v Pascalu a nikde se v těch školách v daných předmětech neučilo žádné grafické API, tudíž mě programování ve kterém byl výstup maximálně někde do prostředí Dosu ani nebavilo. Ale dal jsem se na HTML/CSS/JavaScript/PHP a v tom si bastlil nějaký svý weby. Tehdy PHP taky objekty rozvinuté nemělo a na ty svý výtvory jsem to ani nepotřeboval. Takže někdy věci řeším tak, že to prostě dám do html a v tom to zpracovat umím.


K většímu využívání objektů se dostávám až teď (byť tedy v Libre Basicu) a teprve nyní tomu přicházím na chuť. Jenže neučím se nic nijak systematicky, třeba slovo instance ani nevím co znamená, já z oficiální programátorské terminologie vůbec znám velmi málo; a že něco je např. DLL v Javě, tak to jsem sice schopen pochopit, ale jinak s tím žádné zkušnosti nemám :-). Veškeré mé programování je v podstatě podřízeno vytváření mého transkripčního superbastlu, kde na to jdu většinou tak jak jsem to uměl ze škol + Javascriptu či PHP a kde si člověk pořád před lety musel vytvářet své funkce které vše dělaly krok po kroku (pokud si to nechtěl zpomalovat nějakými předtvořenými knihovnami ze kterých využil jen něco). Tudíž některé věci které někdo považuje třeba za "jasný učebnicový základ" nebo jak vy třeba nazýváte "typická práce v Calcu" ani neznám a jsem kolikrát velmi příjmeně překvapen, že Libre má všelijaké funkce které jednoduše udělají to, co by se jinde muselo dělat mnohem obsáhleji a ve více krocích.

Offline

Zápatí