Ve spolupráci se společností

Wiki datových schránek

Na webu by měla v následujících měsících vyrůst vyspělá encyklopedie datových schránek. Objeví se zde návody a články sahající od úplných základů po (doufejme) nejodbornější právní i technickou problematiku.

Web Datoveschranky.com by tak měl brzy obsahovat pokud možno všechny údaje a novinky k datovým schránkám.

Program Evolio – Datové schránky

Web také slouží jako ukázka aplikace Evolio – Datové schránky. Ta pracuje hned s třemi druhy zpráv:

• s datovými schránkami,
• s e-maily a
• s listinnou poštou.

Evolio tak zastane práci drahého Microsoft Outlook s poštovním software Exchange či Lotus Notes, a navíc „pod jednou střechou“ soustředí evidenci veškeré elektronické i papírové pošty.

Evolio vyniká tím, že je:

• ovladatelné (jako Outlook) pro začátečníky, a zároveň
• obohacené o velmi pokročilé funkce.

K pokročilým funkcím se řadí např. doplňování adresáře kontaktů z ARES či obchodního rejstříku, přidělování doručených zpráv uživatelům, schvalování odchozích zpráv, časová razítka u příloh datových zpráv a e-mailů, napojení na databázi poštovních adres MPSV, automatizovaný tisk obálek, automatizovaná práce s doručenkami atd. Evolio může běžet jak na jediném počítači tak i v režimu klient-server pro více uživatelů.

Program je vhodný zejména pro samostatné advokáty a daňové poradce, neboť obsahuje pro ně klíčovou funkci – časová razítka – a v ceně programu je obsaženo několik uživatelských licencí.

Více informací o Evoliu naleznete na http://www.datoveschranky.com/popis-evolia/. Na webu je možné stáhnout zkušební verzi a také je možné program i zakoupit a zaplatit.

Problém

Prvek SiteMapPath se ve výsledné HTML stránce vykresluje prázdný, tzn. obsahuje nanejvýš tzv. SkipLink (prostředek pro čtečky obrazovek k přeskakování „breadcrumb“ menu).

Možná příčina

Pomineme-li běžné příčiny, může to být způsobeno také tím, že soubor Web.sitemap obsahuje tzv. platformně nezávislé cesty. Tedy jen „http://server/cesta/“ a ne „http://server/cesta/default.aspx“.

Řešení

• buď používat „ošklivé“ plné cesty včetně názvů souborů;
• nebo použít doplněk ScionSiteMapProvider.

Tento provider umožňuje používat čisté a krátké adresy a má i několik dalších výhod.

Problém

Při psaní ASP.NET MVC 2 aplikace je možné v datové vrstvě (modelu) nastavovat atributy jako jsou user-friendly popisné názvy vlastností ([DisplayName(“Nějaký hodně dlouhý název pro nějakou Int32 hodnotu”)]), validační hlášky (např. [Required]), skrývání ([HiddenInput]) apod.

Tyto atributy se zapisují přímo do tříd datového modelu. A to znamená problém, pokud se datový model generuje pomocí Entity Frameworku (s pomocí jeho vizuálního editoru). Uživatel si sice může do code-behind tříd vepisovat atributy, nicméně po téměř každé drobné změně modelu s pomocí vizuálního editoru se znovu vygenerují code-behind třídy. A samozřejmě už bez ručně zadaných atributů.

Řešení

Žádné zcela elegantní řešení, jak zakázat Entity Frameworku přepis atributů, neexistuje. V úvahu přichází vytvořit si wrapper třídy, ve kterých otrocky přepíšeme všechny entity i všechny jejich vnitřní vlastnosti (vlastnostem přidáme atributy), a potom v aplikaci pracovat s těmito wrapper třídami. Uff.

Naštěstí existuje jakési polo-elegantní řešení. Vytvořit si v jmenném prostoru modelu zcela prázdné partial třídy se jmény původních entit, opatřit je atributem [MetadataType(typeof(NejakaEntitaMetadata))]. Dále je potřeba vytvořit odpovídající třídy NejakaEntitaMetadata, a v nich (bohužel) otrocky převyprávět ty vlastnosti, které mají mít u sebe nějaké atributy.

Díky tomuto polo-řešení alespoň není potřeba v aplikaci pracovat s nějakými wrapper třídami. Dále je možné používat původní entity, tentokrát i s atributy, ovšem už bez ohledu na Entity Framework a generovaný kód.

How to keep MVC 2 ModelMetadata attributes with Entity Framework

There is a slight mention of this problem in the web but it is really underhand.

The Problem

When writing an ASP.NET MVC 2 application it’s possible to furnish data entitites in the data access layer with ModelMetadata attributes. These can be some user-friendly descriptions of properties ([DisplayName(“Some really long caption for some Int32 value”)]), validation alerts (like [Required]), property hiding ([HiddenInput]) and so on.

These attributes should be written down directly to data model classes. And this causes a serious problem in case the model is being generated by Entity Framework’s visual editor. Although the user can write his attributes to the EF code-behind classes, these attributes get lost after even a single change has been made within the visual editor.

Solution

Unfortunately there is no elegant way of forbidding the Entity Framework to overwrite hand-coded attributes. You can create wrapper classes that incorporate all entities with all their properties, but you would have to work with these wrapper classes in the application instead of those original ones. Ugh.

Luckily you can use this semi-elegant workaround. Just create partial classes on top of those original entity classes in the model’s namespace. Then, equip them with [MetadataType(typeof(SomeEntityMetadata))] attributes. Create corresponding SomeEntityMetadata classes, declare properties that you would like to have attributes.

Thanks to this semi-elegant-workaround you are still able to work with original entity classes in your application. And your entities will have attributes set no matter what happens in the EF.

Pokud pohled obsahuje vyhledávací formulář s několika typově silnými rozbalovacími menu (Html.DropDownListFor), stane se díky této chybě to, že odpovídající property ve vyhledávacím controlleru bude null.

Pokud kompilátor není schopen odvodit typ parametru, měl by už při psaní kódu správně hlásit toto:

„The type arguments for method … cannot be inferred from the usage. Try specifying the type arguments explicitly.”

Nic takového ale uživatel neuvidí. Nanejvýš se dozví o obecné chybě v LINQ výrazu vyhledávacího controlleru.

Řešení

Chyba se dá obejít tak, že sami v zápisu helper metody ručně určíme typ modelu i typ property. Kompilátor se v takovém případě nesnaží odvodit typy z lambda výrazu a nemá tedy co pokazit.

Quick shot: Error in type inference in ASP.NET MVC 2 views

There is an undocumented error in ASP.NET MVC 2. In case there is more than just a few type safe HTML helper methods in the view, the compiler may cease to infer these method’s parameters types correctly.

Example: A search form with several strong drop down menus (Html.DropDownListFor) will not function because the corresponding property in the search controller will be null. (See the first picture above.)

In normal circumstances the compiler should give a following error:

„The type arguments for method … cannot be inferred from the usage. Try specifying the type arguments explicitly.”

But the user will not see anything like this. Most probably a generic LINQ expression error will pop up.

Workaround

You can avoid this erratic behavior by explicitly stating type parameters in those helper methods. (See the second picture.)

Tajemný jako hrad v Karpatech

Publisher se tváří jako entry-level aplikace, tedy nemá ambici stát po boku profesionálních nástrojů jako QuarkXPress či třeba PageMaker. To se dočteme ve všech materiálech Microsoftu. Co přesně ale Publisher zvládá a co ne, to se nedá nikde zjistit.

O Publisher jsem se zajímal už před třemi lety, když jsme v Oddělení dokumentace a analytiky na Nejvyšším správním soudu zvažovali, že budeme vydávat Sbírku rozhodnutí Nejvyššího správního soudu vlastními silami, bez zdlouhavé spolupráce se soukromým vydavatelstvím. Na sazbu takové sbírky se mi zdál Publisher ideální. Netušil jsem ale, že ani na toto by – díky jednomu drobnému nedostatku – nestačil.

Už po několika kliknutích jsem zjistil, že Publisheru schází mnoho funkcí, které má Word, a některé zde existují ve velmi omezené podobě. Oproti Wordu má Publisher navrch vlastně jen tehdy, kdy uživatel chce:

• tisknout brožury (sešity);
• tisknout pomocí pokročilých nastavení oboustranného tisku;
• vytvářet publikace s vzájemně propojenými textovými poli (s přetékáním textu z jednoho do druhého);
• vytvářet tištěné kalendáře;
• mít větší kontrolu nad obtékáním textu okolo obrázků s nepravidelnými okraji.

Verze 2010

V současné verzi 2010 nabízí Publisher nové uživatelské rozhraní s pásem karet, pod tímto kabátem se ale skrývá jen mírně vylepšená původní aplikace. Změnilo se jen pár drobností:

• Přibyla možnost opatřit obrázek titulkem. Vytvořit seznam titulků na konci publikace, jako to umí Word, ale nelze.
• Je možné vzájemně prohodit dva obrázky, případně pouze jejich formátování. Taky je možné měnit zdroj obrázku pomocí drag-and-drop.
• Obrázky mohou být oříznuty do nepravidelných tvarů s pomocí ořezových bodů (vektorů).
• Mírného vylepšení doznaly zástupné symboly obrázků a systém umisťování objektů na stránce.
• Nová funkce Stránky katalogu, která umí podobně jako Hromadná korespondence získávat data (a pomocí těchto dat i obrázky) z datových zdrojů a dosazovat je do zástupných symbolů na stránce.
• Existuje nyní i 64bitová verze.
• Nyní je možné ukládat publikaci do formátů PDF a XPS.
• Publisher podporuje OpenType funkce jako jsou stylistické sady, ligatury apod.
• Při oboustranném tisku se dá zobrazit náhled stránky „prosvíceně”.

Filozofie práce

Předpokládal jsem, že Publisher existuje hlavně proto, aby autor publikace (nebo třeba tým spoluautorů) nejprve napsal text spolu s tabulkami a obrázky ve Wordu, exportoval jej do Publisheru a tam vše vyladil pro tiskové účely. Ani to se nepotvrdilo.

Ve Wordu by si uživatel měl raději napsat pouze mírně formátovaný text, případně s obrázky, nicméně pokud možno bez tabulek. A měl by si text roztřídit do jednotlivých stylů. Víc by raději ve Wordu dělat neměl. Před importem do Publisheru by si měl uživatel pořádně rozmyslet, jak nastavit okraje stránky. Publisher totiž při importu automaticky vytvoří potřebný počet stránek a v každé z nich vytvoří textové pole podle okrajů první stránky. Pokud uživatel importuje texty, provede další úpravy a teprve pak zjistí, že má okraje stránky nastavené špatně, může začít od píky. Po změně okrajů stránky se totiž velikost textového pole na stránce nezmění. Žádný způsob, jak hromadně upravit objekty (textová pole) na více či všech stránkách publikace, jsem neobjevil.

Importy

Při importu se tabulky z původního dokumentu přetahují se svou původní faktickou šířkou, i přesto, že v původním Wordovém dokumentu měly šířku nastavenou s pomocí procentní hodnoty šířky stránky. Proto je lepší si je vytvořit až v samotném Publisheru. Zvláštní.

Při importu se občas stane, že se u některých stylů bezdůvodně změní font. Konkrétně se mi několikrát stalo, že se u stylu „Bez mezer” (který se od stylu „Normální” liší pouze výškou řádkování) najednou po importu objevil jiný (často bezpatkový) řez písma.

Pokud původní Wordový dokument obsahuje poznámky pod čarou, vysvětlivky nebo citace, do Publisheru se nepřevedou. Ostatně, Publisher poznámky pod čarou vůbec nepodporuje, nedají se vytvořit ani ručně po importu. Kvůli tomuto nedostatku se Publisher nedá použít pro žádné vědecké publikace, sbírky soudních rozhodnutí a podobné tituly.

Taky není možné importovat XML dokumenty, jako to umí například LaTeX.

Světlé stránky

Pokud vyjdeme z úvahy, že Publisher je něco jako odvozenina Wordu určená jednostranně pouze pro některé náročnější tiskové účely, a ne profesionální DTP software, dá se u něj mluvit o několika opravdu užitečných vlastnostech.

Tak například, tisk brožur je s Publisherem hračka. Při náhledu tisku si uživatel zvolí tuto možnost a Publisher mu propočítá všechny přední i zadní stránky. A je možné si nechat listy při náhledu prosvítit a vyvarovat se tak nepříjemných překvapení při samotném tisku. Dají se však tisknout jen dvě stránky na list, čtyřstránkové listy Publisher neumí.

Díky možnosti zobrazení účaří může mít uživatel v určitých chvílích mnohem lepší kontrolu nad sestavením vícesloupcových publikací a taky nad obtékáním textu okolo plovoucích objektů s nepravidelnými okraji.

Hodně užitku mi přinesla jedna jednoduchá funkce: klávesa Tab, pomocí níž se postupně přemisťuje kurzor (focus) z jednoho objektu na stránce na druhý. Pokud se na stránce nachází objekt, který se schovává za jinými objekty, není nutné pořád objekty skrývat, nebo jej hledat v nějakém podokně výběru. Mimochodem, podokno výběru Publisher nemá.

Uživatel má také možnost zobrazit si i při samotné práci (tedy ne jen v náhledu tisku) protější dvojstránky tak, jak budou vypadat při tisku. Word umí samozřejmě taky zobrazit dvě stránky vedle sebe, nebere při tom ale v potaz, že první a druhá stránka zpravidla nestojí naproti sobě. Ale hlavně – při zobrazení dvojstránek se dají doprostřed dvojstránky umisťovat objekty, takže se zobrazí a vytisknou rozloženě na obou protějších stránkách. To Word nezvládne.

Pokud se uživatel rozhodne odstranit stránku (stránky), Publisher zkontroluje, zda to nerozhodí páry protějších stránek. Pokud ano, uživatele upozorní a dá mu možnost couvnout.

Stinné stránky

V Publisheru se dají vytvářet kalendáře v měsíčním zobrazení. Kalendáře mají povahu stavebních bloků, takže stačí zvolit si měsíc, rok a místo, kam jej chce uživatel do publikace vložit. Potíž ale nastává ve chvíli, kdy uživatel v již vloženém kalendáři provede nějaké formátování a pak zjistí, že kalendář má zobrazovat jiný měsíc. Změnu měsíce už provést nemůže.

Trochu problematicky působí i funkce Stránka předlohy, která slouží k sjednocení vzhledu stránek. Dá se dobře využít, bohužel se ale při práci stává, že uživatel musí pořád přepínat mezi zobrazením normálním a zobrazením stránky předlohy.

Při vytváření publikací s barevnými fotografiemi citelně schází možnost zobrazit histogram obrázku a případně upravit světlá místa a stíny s pomocí křivek.

Jak jsem zjistil, volba pásu karet Formát > Upravit > Přebarvit není totéž co volba dialogového okna Formát obrázku > Obrázek > Vzhled obrázku > Barva. Vzhledem k tomu, že ostatní volby v dané skupině pásu karet už odpovídají příslušným volbám v dialogovém okně, trochu to mate.

Publisher, stejně jako Word, obsahuje chybu ve funkci Hromadná korespondence. Při vkládání zástupného symbolu s oslovením se namísto jména a příjmení vloží pouze náhradní oslovení „Vážený pane, vážená paní”.

V jedné publikaci se navíc nedají použít naráz funkce Hromadná korespondence a Stránky katalogu. Publisher, stejně jako Word, neumí kombinovat dva datové zdroje, takže se asi nic jiného čekat nedalo. Ve Wordu se dá tento nedostatek překlenout tak, že se dva (více) původní datové zdroje před použitím v dokumentu sloučí do jednoho (databázový JOIN, statické sloučení do excelového sešitu). V Publisheru se taková objížďka dá vytvořit samozřejmě také, jen to uživateli nemusí hned dojít. A nápověda Publisheru o tom mlčí.

Když už je řeč o nápovědě, tak v ní se nachází několik článků (i v on-line verzi stahované z webu) přímo převzatých z verze 2007. Takže se zde často hovoří o „aplikaci Publisher 2007”, o nějaké položce „v nabídce X a podnabídce Y” místo „v kartě X a skupině Y”. Tento problém provází i nápovědy ostatních aplikací Office 2010, v nápovědě Publisheru se však nachází chyby i v částech, které už o verzi 2010 vědí. Nápověda někdy směšuje „karty” se „skupinami” a vůbec používá nestejné pojmy pro jeden a tentýž jev. Například skupina Styly obrázků se v nápovědě často nazývá Nástroje obrázků.

O tabulkách už byla řeč při importu. Ještě však musím zmínit, že tabulky se dají umisťovat buď jen jako plovoucí objekty, nebo jako in-line objekty umístěné přesně k levému (pravému) okraji stránky. Pokud by uživatel chtěl tabulku odsadit k nějakému konkrétnímu tabulátoru, nejde to. Tabulce se sice dá nastavit odsazení od okolního textu, to ale funguje jen jako vnější okraj (prázdné místo) mezi tabulkou a textem (např. při umístění tabulky jako plovoucího objektu). Nemá to vliv na umístění tabulky na stránce.

V tabulkách se dá vypnout automatické dělení slov (v Publisheru se primárně slova dělí a je potřeba dělení v případě potřeby vypnout). V okolním textu pak dělení slov zůstane. Bohužel se ale nedá vypnout dělení slov pro určitou buňku tabulky. Dá se vypnout jen pro tabulku jako celek.

Co se týká dělení slov, tak ručně rozdělené slovo se zpravidla chová jako dvě slova spojená spojovníkem – nedá se např. vybrat dvojklikem.

Diagonálně přeškrtnutá buňka tabulky zobrazuje svůj obsah jen z půlky, ne zcela jako ve Wordu či Excelu.

Je třeba dávat pozor i na to, že Publisher uživatele před tiskem nijak neupozorňuje na to, že text či obrázky přesahují tisknutelnou oblast dané tiskárny. Existuje pouze jediné místo, kde se uživatel dozví hodnoty tisknutelné oblasti – malý znak „i” nad volbou tiskárny.

Při přípravě publikace formátu A5 a A6, kterou uživatel tiskne na společné archy formátu A4, se občas stává, že z ničeho nic Publisher označí formát A4 jako „nepoužitelný formát papíru”. Důvod i řešení problému zůstávají skryty.

Malé úskalí číhá na toho, kdo by chtěl exportovat barevnou publikaci s RGB barevným modelem pro komerční tiskárnu (do PDF nebo třeba XPS). Při exportu si uživatel nastaví barevný model CMYK, ale ouha, barvy se převedou i v původní publikaci, ze které se provádí export. S tím je třeba počítat a případně po exportu vrátit barevný model zpět.

Hodně mě zamrzelo i to, že Microsoft přidal do Wordu funkci Odstranit pozadí obrázku, a v Publisheru na ni zapomněl. Přitom právě v Publisheru by se opravdu hodila. Sice se u obrázku dá nastavit průhledná barva, tato funkce má ale k dokonalosti opravdu daleko. Jednak se nedá nastavit rozsah sousedních barev, které se budou považovat za průhledné. A pak taky se nedá nastavit konkrétní jmenovitá barva, pouze se dá vybrat určitý bod v bitmapě s pomocí kapátka.

K čemu se proboha ten Publisher vlastně hodí (závěr)

Rozhodně se Publisher nedá použít na nějakou graficky bohatou publikaci. Kdo jednou kreslil vektorovou grafiku v CorelDRAW, nebude to tady ani zkoušet, už jen pro tu namáhavost. Bitmapová grafika se používat sice dá, ovšem pro každou drobnou změnu fotografie je potřeba složitě odběhnout do grafického editoru a pak obrázek znovu načíst.

Paradoxně se Publisher často nedá použít ani pro ten pravý opak – pro nudné textové publikace bez grafiky. V nich se totiž často používají poznámky pod čarou, vysvětlivky a citace, které Publisher nezvládá.

Rozhodně bych nedoporučoval pořizovat Publisher jen proto, aby tisknul wordové dokumenty v brožovaných výtiscích (sešitech). V takovém případě doporučuji zůstat u Wordu samotného a pořídit k němu utilitu FinePrint.

Pokud bych měl uvést typický scénář nasazení Publisheru, pak by se podle mě dal zcela bezpečně použít pro sazbu nějakých městských (obecních) novin. Do takových městských novin není potřeba vkládat poznámky pod čarou, nevkládá se do nich zpravidla žádná oslňující grafika, a nevadí, že někdy fotografie trochu „ujedou” v barevném nastavení.

Popis problému č. 1

Prostě, jede to pomalu, hodně pomalu. Můj UPC Fiber Power 10 s reálnou rychlostí stahování 16 Mbps a rychlostí odesílání 1,6 Mbps se díky tomuto routeru proměnil v necelých 3,6 Mbps stahování a 100 kbps odesílání. A přitom D-Link DIR-655 je plně gigabitový (má gigabitový i WAN port) router, který v kombinaci s Corsair P128 SSD diskem zvládá ve vnitřní síti i 100 až 120 MB za sekundu.

Řešení problému č. 1

Problém tkví v automatickém nastavení QoS. Stačí zrušit zaškrtnutí u „ADVANCED > QOS ENGINE > WAN TRAFFIC SHAPING > Automatic Uplink Speed” a do „Manual Uplink Speed” zadat rychlost uploadu providera.

Taky doporučuji zrušit zaškrtnutí u „SETUP > NETWORK SETTINGS > ROUTER SETTINGS > Enable DNS Relay”. Podle mých zkušeností je rychlejší, když se stanice dotazují DNS serverů providera, než když se dotazují DNS cache routeru. V nejnovějších verzích firmware (1.34EU) by se už zpomalení údajně nemělo projevovat, ale stejně to trochu brzdí.

Popis problému č. 2

V kombinaci s kartou Intel 4965AGN se projevuje citelný lagging. Zadrhává se prakticky každý request, pokaždé na 5 až 10 vteřin.

Řešení problému č. 2

Tkví tentokrát na straně karty. Ve správci zařízení stačí změnit „Ochrana smíšeného režimu” na „RTS/CTS povoleno”.

Další drobné problémy

Občas se stávalo, že se můj Dell Latitude D630 s kartou Intel 4965AGN neprobudí z režimu spánku. Od doby vyřešení problému č. 2 se to ale neprojevuje. Update: Bohužel se to stále projevuje. Bude to nejspíš kartou, protože se to projevuje i v jiných sítích. Kdybyste ně to někdo přišel, budu vděčný za radu.

Nebudu popisovat zkouškové otázky, abych zkoušku svým popisem někomu usnadnil. Jednak by to bylo nemorální, nemělo by to navíc ani smysl, a konec konců mi to zakazuje Non-Disclosure Agreement. Rád bych ale na tomto místě upozornil všechny, kteří si myslí, že se v testových úkolech (otázkách) nebudou vyskytovat dvojsmysly (bez pochopitelného účelu) a případně dokonce i chyby. Zbytečných dvojsmyslů, jejichž účelem zjevně nebylo prověřit znalosti, nepřesností a vyložených chyb se v testu může objevit opravdu hodně.

Může se například stát, že testový úkol bude požadovat, aby uživatel provedl v aplikaci nějakou akci s určenými parametry. Bohužel však testový úkol požaduje nastavit parametr, který tato akce vůbec nemá. V takové chvíli má nevýhodu paradoxně ten zkušenější uživatel, který ví, u kterých dalších funkcí se dá nastavit právě tento výslovně uvedený parametr. Přemýšlí nad tím, kterou jinou funkci mohli mít autoři zkoušky na mysli, a zbytečně ztrácí drahocenný čas.

Častěji však testový úkol po uživateli chce, aby dosáhl určitého cíle a užije k tomu (záměrně) ne zcela jednoznačné názvosloví. Potud je vše v naprostém pořádku. Uživateli z toho pak, po úvaze, vypadne určitý postup. Nicméně v závěru zadání tohoto úkolu se zničehonic objeví formulace, ze které jasně vyplyne, že autoři s takovým postupem vůbec nepočítali. Opět pak zbytečně ubíhá čas.

No a vrchol všeho nastane ve chvíli, kdy zadání úkolu obsahuje přímo překlep, u nějž má uživatel pochybnosti, zda se o překlep jedná či ne. Jako když máte z připraveného seznamu jmen „Petr1”, „Petr2” a „Bedřich1” provést určitou akci na jménu „Petr3”, které se v seznamu vůbec nevyskytuje. Každého to pak donutí přemýšlet, zda snad náhodou není položka „Petr3” skryta pomocí nějaké deep-down-hidden funkce. Jistotu, že taková funkce neexistuje, má ovšem pouze expert na daný produkt. Pro něj jsou ovšem určeny úplně jiné úrovně certifikace. Takže pokud snad Certiport do zkoušky dal takovýto překlep záměrně, nemá to pražádný smysl.

Mimo toto vše jsem ještě u zkoušek nabyl dojmu, že i tak příbuzné zkoušky jako Word a Excel u Certiportu připravují odlišné skupiny lidí a zjevně nad nimi nestojí žádný společný redaktor, který by sladil terminologii a filozofii kladení otázek (tam, kde je to možné a vhodné). Uvedené dvojsmysly a chyby jsem zaznamenal spíše jen u zkoušky Wordu, u Excelu už tolik ne.

Vzhledem k tomu, že vykonání zkoušky stojí nemalé peníze a leckdy i čas (na přípravu, dojezd do testovacího centra), očekával bych od Certiportu trochu zodpovědnější přístup. Když vezmu do úvahy, že všichni otestovaní jsou vázáni naprostou mlčenlivostí, vychází mi z toho, že bych vlastně moc rád pracoval u společnosti, kterou nemůže nikdo pomluvit za špatně odvedenou práci.

Na závěr uvedu krátký výňatek z NDA Certiportu:

„Examinee is expressly prohibited from disclosing, publishing, reproducing, summarizing, paraphrasing, or transmitting these examinations …”

Z pohledu právníka to hodnotím jako sice částečně platné, jinak však „velmi úsměvné” ustanovení.

Obecně se dá říct, že Microsoft měl u Office 2010 za cíl přinést spíše dokonale přívětivé, intuitivní a promyšlené uživatelské prostředí, ne nové funkce. Stávající funkce pak měly doznat přiměřených změn, aby na jednu stranu odpovídaly požadavkům uživatelů, kteří požadovali jejich změnu, ale aby se v nich neztratili ti uživatelé, kteří jsou zvyklí na jejich dosavadní podobu.

Zlidštit uživatelské prostředí se Microsoftu podařilo splnit úžasně. Office 2010 už ve všech aplikacích (až na pár utilit) používá tzv. pás karet, který nahrazuje dosavadní tlačítkové panely. Pás karet se už objevil v některých aplikacích Office 2007, tam mě ale moc nenadchnul. Dlouho jsem se nemohl smířit s tím, že ikonky na pásu karet měnily velikost a uspořádání pokaždé, když jsem změnil velikost hlavního okna aplikace. I dodnes to u mě občas způsobuje, že se v pásu karet ztratím a hledanou ikonku přehlédnu. Nicméně je to celkem přijatelná daň za to, že se podařilo vyřešit tu spoustu problémů dosavadní dichotomie „základní nabídka + tlačítka”. Tlačítka totiž celkem zbytečně suplovala základní nabídku (proč mít dva téměř stejně snadné způsoby dosažení téhož výsledku), a co hůř, uživatelům bez dostatečné míry soudnosti se často stávalo, že si na obrazovku přidali tolik tlačítek, že už jim nezbylo žádné místo pro samotný dokument. Pracovat v aplikaci, kterou chvíli přede mnou používal někdo jiný, často znamenalo nutnost nejdříve ručně zresetovat celé uživatelské prostředí, aby se v tom člověk vůbec vyznal. Pás karet v Office 2010 doznal výrazného zjednodušení a už opticky neruší žádnou spoustou linek jako u verze 2007. Uživatele už z toho nemusí bolet oči.

Co se týče nových funkcí, jsou výborné. A je možná jen dobře, že jich Microsoft nevytvořil tolik (alespoň co se Wordu týče).

U těch dosavadních ale občas překvapí, že stále ještě fungují jinak, než jak by si BFU („běžný franta uživatel”) zpravidla přál. Někdy ale verze 2010 příjemně překvapí a funguje už přesně tak, jak má.

Revize

U revizí mě trochu zamrzelo, když jsem zjistil, že je sice možné sledovat přesouvání položek (Revize > Sledovat změny > Změnit možnosti sledování > Sledovat přesunuté položky), nicméně to se nevztahuje na menší prvky textu než odstavce. Kdo chce sledovat přesouvání vět či slov, má smůlu.

Pokud navíc některý odstavec obsahuje komentáře a přesune se na nové místo, zobrazují se komentáře u obou výskytů odstavce – u původního (přeškrtnutého) i u nového. Na tom by nebylo nic špatného, kdyby se ovšem při změně komentáře synchronizovaly změny. Nebo kdyby alespoň existovala možnost takto Word nastavit.

Pokud se v dokumentu nachází tabulka a je zapnuté sledování změn, při mazání sloupce této tabulky Word zahlásí, že tuto změnu sledovat nebude. Jistě pro to tento nedostatek existují nějaké technické důvody, každopádně škoda.

Korespondence

Několika nemilých překvapení se uživatel dočká i u hromadné korespondence. Dnes už se tato funkce asi příliš nepoužívá (spíše pouze v podobě hromadných e-mailových zpráv), takže nedostatky žádnou katastrofu neznamenají.

Při vytváření obálek uživatelé často mění výchozí umístění adresy. Ve výchozím nastavení adresa někdy trochu utíká doprostřed obálky. Dá se nastavit přesné nebo automatické umístění, a to jak ve svislém tak i ve vodorovném směru. Malá past na uživatele ale čeká v případě, že se rozhodne nastavit v jednom směru automatické umístění, ve druhém směrem pak ruční nastavení (přesnou vzdálenost). Pokud v dialogu potvrdí takovéto nastavení a dialog zavře, nastaví se umístění automaticky v obou směrech a milý uživatel může začít umisťovat znova. Nakonec tedy zjistí, že musí nastavit obojí, vertikální i horizontální umístění na určitou přesnou hodnotu, nebo obojí automaticky.

Drobný nedostatek se projevuje při vytváření archů s adresními (nalepovacími) štítky. Po změně formátu nebo počtu štítků na jeden list papíru je občas potřeba ručně opravit zalomení v textu adresy. Mělo by to jít vyřešit s pomocí hromadného nahrazování textu.

Po načtení seznamu příjemců z databáze MS Access se může stát, že v okně se seznamem příjemců uživatel omylem vytvoří na konci seznamu zcela prázdný záznam, pokud po úpravách údajů posledního příjemce stiskne tabulátor. Tento nechtěný nový a prázdný záznam se dá smazat jen pomocí Accessu. Záznam se ale samozřejmě dá vyloučit z tisku, takže opět – žádná pohroma.

Pro vložení řádku s pozdravem je zapotřebí, aby uživatel nejprve ručně spároval potřebná pole datového zdroje s poli užívanými Wordem. Jinak se po zobrazení náhledu v místě řádku s pozdravem objeví pouze text „Vážený pane, vážená paní,” (záchranný text pro případy neplatných jmen příjemců). Po ručním spárování už funkce pracuje správně.

Pokud chce uživatel ve zpáteční adrese použít firemní logo, je stále zapotřebí jít oklikou a použít AutoTextové pole „ObálkaExtra1” (nebo „EnvelopeExtra1” v anglické verzi).

Zobrazení osnovy

V zobrazení osnovy se pořád vykreslují tlačítka Sloučit a Rozdělit zašedlé (disabled). Asi jsem něco nepochopil správně, ale nepodařilo se mi přinutit Word, aby vnořené dokumenty sloučil či rozdělil.

Zřejmě taky nelze Word přinutit, aby po otevření hlavního dokumentu (master document) rovnou otevřel vnořené dokumenty, a ne pouze zobrazoval hypertextové odkazy na ně vedoucí.

Titulky

Titulky k obrázkům, tabulkám či rovnicím mají ještě jednu „mouchu”. Pokud uživatel vloží do dokumentu obrazec, přidá dovnitř obrazce text a otočí tok tohoto textu, může očekávat, že se přiložený titulek otočí stejným směrem.

Ale abych pořád jen nehanil – zmizela jedna nepříjemná vlastnost. V dřívějších verzích se stávalo, že se seznam titulků tvořil jen z titulků umístěných tzv. inline (v řádku) a vynechávaly se titulky umístěné v plovoucích textových polích. To už ve verzi 2010 naštěstí neplatí.

Další postřehy

Oklikou se musí ještě pořád chodit v případě, kdy uživatel chce do bloku vybrat veškerý text dané stránky. Je potřeba otevřít dialog Přejít na (Ctrl+G) a do textového pole vepsat „\page”. Jedna položka navíc by v menu Domů > Úpravy > Vybrat určitě neškodila.

Trochu nesmyslně se zdají být nastaveny funkce Porovnat a Sloučit. Pokud se dokumenty již značně liší, nastane zvláštní situace, když uživatel nejprve dokumenty porovná a pak sloučí. Funkce Porovnat v takovém případě zařadí texty revidované verze dokumentu dozadu za původní dokument, kdežto funkce Sloučit je zařadí dopředu. Zvláštní.

Při vytváření rejstříku dokumentu se, jak známo, dají označovat nejen běžné položky rejstříku, ale i jejich vnořené položky (podpoložky). Taky je známo, že se dá, namísto pracného naklikávání slov z dokumentu, vytvořit tzv. konkordační soubor. Pokud do něj uživatel vloží dvousloupcovou tabulku, může do ní pohodlně a rychle zapsat jednotlivé hlavní položky rejstříku. To vše je možné v nápovědě vyčíst. Nikde se ale nepíše, jak do konkordačního souboru vepisovat vnořené položky. Toto moudro je třeba hledat na webu. Vnořené položky se zapisují do pravého sloupce ve formátu “Hlavní položka:Vnořená položka”.

Nakonec přidám ještě jednu menší pochvalu (vztahující se i k verzi 2007). Vodoznaky se na stránkách dokumentu nemusejí zobrazovat jen tak, jak je naformátoval Word podle údajů zadaných v dialogovém okně. Vodoznaky mají povahu jednoho z prvků záhlaví, takže pomocí dvojkliku v oblasti záhlaví stránky je možné jej libovolně upravovat.