Čuňačíme v MediaWiki - responzivní obsah II. (diskuse)

[Kol0brndaRulez]

No nádhera, jako blesk. Zavzpomínal jsem na dialup, díky.

[Aleš Kapica]

Zkus otevřít a na mobilu číst srovnatelně velký 245 stránkový PDF soubor

[_]

S dobrym pdf prohlizecem naprosto bez problemu a bez jakehokoliv uzivatelsky vnimatelneho lagu pri skrolovani.

[Aleš Kapica]

Neříkej, že ti ta html stránka po tom několikasekundovém načtení při procházení laguje. Mám 6 let staré BlackBerry Q10, načte se mi to cca během 8 sekund a procházení je zcela bezproblémové.

Abych řekl pravdu, kolikrát mi trvá mnohem déle načtení, z hlediska dat mnohem jednodušší, stránky z abclinuxu.cz

[Josef Kufner]

Však PDF je navržené tak, aby se dalo načítat postupně a jen to, co je na aktuální stránce potřeba. Problém může být jen pokud ta jedna stránka je příliš komplikovaná ci blbě udělaná.

[Aleš Kapica]

Je to smutné, ale většina PDF je udělaná blbě. Ale co hlavně, účelem PDF nebylo pohodlné a rychlé prohlížení elektronických dokumentů, ale jejich tisk. Až dodatečně do něj dobastlili další featury.

[marbu]

Ta wikistránka je pěkná ukázka (nebo spíš benchmark? šablon, ale pro čtení knížky na počítači bych spíš volil ten zdrojový DjVu/PDF soubor, a pro čtení na mobilu epub. Ne že by nebylo užitečné mít všechno na jedné html stránce, ale pro čtení samotné se to imho zrovna moc nehodí.

Btw je škoda, že na wikipedii nebo wikizdrojích funkci epub exportu nemají. Jednak příslušné MediaWiki rozšíření Extension:EPubExport zdá se umřelo, a druhak se správci zdá se rozhodli preferovat pdf export.

[Aleš Kapica]

Pche! Nic není nemožné Udělat něco podobného z té singlepage stránky je brnkačka.

Apropos, na to jsi přišel kde, že se to ke čtení na mobilu nehodí? Načteš to jen jednou a pak už skáčeš po libosti v rámci jedné stránky. Epub stejně není ve skutečnosti nic jiného než ořezané html.

[marbu]

Pche! Nic není nemožné Udělat něco podobného z té singlepage stránky je brnkačka. ... Epub stejně není ve skutečnosti nic jiného než ořezané html.

No právě. Jeden by řekl že díky tomu bude implementace takového exportu ve srovnání s ostatními exporty jednodušší, a tak nebude problém s nasazením na wikipedii.

[Aleš Kapica]

Jednodušší je načíst tu stránku do LibreOffice. Zatím akorát nevím, čím vším se ten import dá ovlivnit. Něco totiž akceptuje a něco ne. Abych byl konkrétní, blbě importuje ty postranní odkazy na stránky – valí to rovnou do textu. Přitom mají class="noprint" a při tisku se ignorují.

Importovaný dokument se ale stejně neobejde bez úpravy. Ten Libreoffice totiž nezachová proporce vložených obrázků (deformuje je), takže se to musí ručně změnit. Ovšem pak už to není problém uložit do čeho chceš, případně vyexportovat do toho PDF.

[marbu]

Apropos, na to jsi přišel kde, že se to ke čtení na mobilu nehodí? Načteš to jen jednou a pak už skáčeš po libosti v rámci jedné stránky.

Pro běžné lineární čtení mi přijde mnohem lepší nějaký program na čtení knih (např. fbreader), který zobrazuje text postupně po stránkách (místro scrolování), zobrazuje jen text a relevantní obrázky a pamatuje si naposledy otevřenou stránku. Z hlediska uživatelského pohodlí je to imho řádově lepší. Navíc jaksi explicitně funguje offline, protože pracuje s knížkami v epub souborech. Zatímco v prohlížeči na mobilu čtu spíše kratší texty, a pokud bych si chtěl takto nějaký dlouhý text uložit na později, abych se k tomu mohl nějakou dobu pravidelně vracet, nemám přímo jak (resp. řeším to přes pocket).

[Aleš Kapica]

Pro běžné lineární čtení mi přijde mnohem lepší nějaký program na čtení knih (např. fbreader), který zobrazuje text postupně po stránkách (místro scrolování)

Je to věc vkusu. Kupř. mi pro čtení víc vyhovuje klasický papírový list. Ovšem ne formát A4 ale cca A5. Ale tisknul bych to jedině v případě, že bych to pak chtěl někomu poslat dál.

Scrollování je pro mne přirozenější, než virtuální "listování". Pokud sis nevšiml, tak na té stránce jsou dva obsahy. Oba skáčou pouze v rámci jedné stránky, takže funguje i back. Alespoň tedy na mém mobilu. Čtu tak, že obrazovku při čtení posouvám palcem. A když se chci na něco kouknout blíž, tak si to zvětším.

Virtuální "listování" mne při čtení ruší a vykreslování stránek zdržuje, protože čtu rychleji, než to stíhají ty čtečky vykreslovat.

[Aleš Kapica]

Mimochodem, kdo neumí česky, ani anglicky, si může ty stránky prohnat přes translator. Není to sice bůhví co, ale s trochou imaginace to dá. S PDF či Epub na něco podobného můžeš rovnou zapomenout.

[Aleš Kapica]

Jo a ten zdrojový DjVu není problém stáhnout. Dostaneš se k němu přes libovolnou stránku. Skočíš na index a pak klikneš na obrázek titulní stránky. To tě hodí na soubor. A odtamtud si to můžeš stáhnout. Má to 6,3MB včetně textové vrstvy.

[Max]

Zajímalo by mně, co se děje na serveru. Pokud to tak dlouho čeká na data, tak to server, resp. db, asi nebude mít lehký?

Jinak mám nasazený parsoid jako backend pro klikaci WYSIWYG a pokud bych ten klikací ksicht měl použít na té stránce, tak asi umře vše :D, aspoň podle těch stránek s dokumentací, co v tom tvořím.
Zdar Max

[Aleš Kapica]

Co se děje? Jak už jsem napsal. Proběhne transkluze cca 245 stránek vygenerovaných přes rozšíření Proofread Page, cca stovky obrázků a řady dalších šablon, včetně kontroly - některé věci na té wiki jsou dostupné jen registrovaným uživatelům s povoleným přístupem.

Wysiwyg editor wiki je zlo. Kód té stránky je ve skutečnosti velmi jednoduchý. I jako anonym bys měl mít možnost si ho zobrazit.

Jinak jde o specifickou stránku. Jsou tam i rozsáhlejší. Generované z cca 600 stran.

[Ehm]

Nechutný, už chápu proč jsi v IT nesehnal nic pořádnýho

[Aleš Kapica]

A tak ne. Anonym si může zobrazit pouze kód z namespace Template. Ale nikomu nic nebrání v registraci. Ta je nezbytná ze tří důvodů. 1, ověřuje se při ní platnost mailové adresy. 2, je to účinná bariéra před škodiči a 3, na základě uživatelských jmen funguje ochrana stránek a nastavení práv k různým operacím a funkcionalitám. Anonym má u mé wiku kupř. jen velmi omezený přístup ke speciálním stránkám, jelikož se dají snadno zneužít k útoku na wiki.

[Aleš Kapica]

Pokud jde o vytížení serveru, není to nic hrozného. Výhodou šablon je mimo jiné to, že unifikují použitý kód. Mimochodem, i hlavní stránka té wiki je generována přes šablony. Ale o šabloně content jsem už tady asi v minulosti psal.

[Max]

Ano, v mém dotazu jsem myslel vytížení serveru.
Zdar Max

[Aleš Kapica]

99% času ten server jede na 2%. Přitom má relativně málo paměti a jen 2 procesorová jádra. Ovšem to se děje pouze při vkládání obrázku. Vtip je v tom, že ta šablona Image pracuje s již hotovým obrázkem, který se pouze procentuálně škáluje (šablona přepočítává parametry pro css) – to je rozdíl oproti tomu jak s obrázky nativně pracuje MediaWiki. Schválně si zkus jak rychle se načte tohle. To se renderuje složením 620 stránek, ale ještě to neprošlo korekturou, takže se nic nedělá s obrázky. Ty to zatěžují asi nejvíc a nejvíc jich má zatím právě ta knížka z Lesní říše.

[jiwopene]

2 % čeho? Pokud je to vytížení CPU během dotazu, tak bych předpokládal, že se čeká na disk.

[Aleš Kapica]

2% vytížení CPU. Ten maká nejvíc když se generují nové náhledy. Pak už se používá to co je vygenerované a změna velikosti se řeší přes css na straně klienta. U velkých stránek jako ta odkazovaná z blogpostu trvá nejdéle, přežvejkání toho co parser dostane z databáze.

Jinak jo, asi čeká na disk, protože ten stroj má poměrně málo RAM. Ale je to v pohodě viděl jsem už výrazně pomalejší servery.

P.S.:Vtipné je, jak se neustále různí boti pokoušejí atakovat Wordpress, který tam neexistuje. A Číňani se zas neustále pokoušejí zneužít mailserver.