Operu jsem jednou zkusil pěkně mě rozčílila, když jsem si v ní otevřel PDF, zmáčkl tisk a vytiskly se mi papíry s URL a rámečkem. Poté jsem zjistil, že tlačítko tisk v pluginu na pdf a tisk v prohlížeči každé udělá něco jiného.
No a hned potom šla pryč, protože to ve mně vyvolalo dojem, že je naprogramovaná prasácky.
V konqueroru takové věci bezproblémů fungují pro všechny pohlcované prohlížeče, co jsem zatím použil (pdf, ps, dvi, kword) a jak zde již někdo psal, v IE7 to se stejným pluginem také jde.
Když jsem po dlouhé době pracoval na windows (ve škole) a chtěl prohlížeč s kartami, tak jsem sáhl právě po opeře a byl jsem nepříjemně překvapen touto chybou. Minimálně autoři mohli tlačítko pro tisk, které v tu chvíli nefunguje deaktivovat (aby nešlo stisknout). Nechápu, proč tu chybu omlouváte, to si opravdu myslíte, že takové chování je v pořádku?
Co se týče Konqueroru, tak defaultně používá kpdf pro renderování pdf. Vzhledem k tomu, že jsou to nativní komponenty KDE, tak se dá očekávat dobrá spolupráce. Kdyby jsi v Konqueroru používal proprietární plugin od Adobe, tak řešíš stejný problém.
Jak říkám, zarazilo mě, že taková jednoduchá věc nefunguje a navíc není ani nijak ošetřena, třeba i jen znepřístupněním tlačítek tisku v případě, že se k zobrazování využívá onen plugin. Navíc by se to (pokud to mají rozumě napsané) dalo zařídit pár řádkami kódu.
Škoda jen, že to vůbec nesouvisí s Operou, ale s tím, jak je napsaný plugin pro prohlížení PDF. Nápověda: zkuste si to samé udělat ve Firefoxu nebo MSIE – vytiskne se vám to samé. Pouze MSIE 7 má implementovanou nějakou logiku, že pokud je ve stránce 1 vložený objekt, a je to plugin pro prohlížení PDF od Adobe, a MSIE usoudí, že uživatel chce tisknout právě jen to PDF (asi má implementovanou křišťálovou kouli), potom tohle chování pluginu obejde tím, že přepošle příkaz pro tisk rovnou do toho pluginu – takže se vám zase vytiskne PDF, ale ne to, co je okolo.