Přihlásit
 
HlavníKnihovnaCertifikaceDownloadPodporaKomunitaFóra
Zdroje informací pro profesionály v oboru IT >
> 
> 
> 
Problém s tiskem čárového kódu v IE9

Odpovědět Problém s tiskem čárového kódu v IE9

  • 1. června 2011 13:44
     
     
    Přihlásit se a hlasovat
    0

    Dobrý den,

    dlouho používáme pro publikování čarového kódu v HTML dokumentech "free" font:
    http://www.squaregear.net/fonts/free3of9.shtml.
    Konkrétně nainstalovaný font ze souboru: fre3of9x.ttf , stažený z balíku:
    http://www.squaregear.net/fonts/free3of9.zip.
    V systému Windows je pak font dostupný jako: "Free 3 of 9 Regular".

    Problém nastal v IE9, kdy při výtisku dojde k posunutí fontu dolů.
    Zajimavé je, že při bežném zobrazení stránky je vše koretkní,
    problém způsobí až render pro tisk / náhled před tiskem.

    Ukázková HTML stránka:
    http://files.cybersoft.cz/Problem-IE9-Code39/default.htm
    Běžně zobrazení této stránky v IE8 i IE9 je totožné.
    Náhled před tiskem už je však jiný.
    PrntScrn z IE8 - zde je běžné zobrazení stránky i náhled stejný:
    http://files.cybersoft.cz/Problem-IE9-Code39/ie8.jpg
    PrntScrn z IE9 - zde dojde k posunu fontu dolů od horní strany bloku:
    http://files.cybersoft.cz/Problem-IE9-Code39/ie9.png
    Tím na stránce font zabere více místa a dojde k posunu dalších objektů, což zrovna při tisku způsobuje problémy.

    Chápu, že tím, že nejsou použity čistě systémové součásti Windows, ale také font třetí strany, není situace úplně jednoduše nasimulovatelná, ale změna v chování IE9/nižší verze tam nějaká je.
    Zkoušel jsem i vynutit režim kompatibility pomocí: X-UA-Compatible - IE=EmulateIE7, ale IE9 se chová stále stejně.
    Kdyby někoho napadlo, jak problém odstranit, tak předem děkuji za info!

    S pozdravem
    Milan Zagora
    CyberSoft, s.r.o.

     

Všechny reakce

  • 1. června 2011 14:01
    Moderátor
     
     
    Přihlásit se a hlasovat
    0
    Ve hre je take tiskarna. Vi se o problemu u tiskaren Canon. Zacal bych asi testem tisku na ruzne tiskarny a nasledne obnovenim driveru pro tiskarnu/y.
     
  • 1. června 2011 14:06
     
     
    Přihlásit se a hlasovat
    0

    Na tiskarne nebyla vypozorovana zavislost, dela to napr. i: Microsoft XPS Document Writer - http://files.cybersoft.cz/Problem-IE9-Code39/ie9print.xps . Problem nam nahlasilo nekolik nasich klientu, kteri pouzivaji ruzne tiskarny.

     
  • 1. června 2011 15:16
    Moderátor
     
      Obsahuje kód
    Přihlásit se a hlasovat
    0

    Dobrý den, nejsem na web kodeřinu zas takový odborník, nicméně na první pohled to vypadá, že IE9 doplní přesně jeden řádek velikosti daného fontu. IE je také znám tím, že v nevalidním dokumentu doplňuje tagy, které mu chybí. Což v HTML5 například již specifikace určuje i jak. Tato vlastnost ovšem může být i kontraproduktivní, zvláště při použití Quirks režimu.

    Vámi odkazovaná testovací stránka se zobrazí v Quirks režimu, což je vidět i v ostrém rámování onoho tagu span. A zde nastává problém s tiskem - posunutý font. Pokud danou stránku zapíši poněkud validnějším kódem, dojde k použití vykreslovacího jádra Trident nejnovější verze a zde již problém s tiskem nenastane - font zůstane v rámečku, jak má. Jak vidno z přiloženého obrázku. Zde ovšem začne fungovat vyhlazování písma (i vykreslování grafickou kartou) a tak je celý výsledek poněkud rozmazanější.

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Font Test</title>
</head>
<body>
<br />
<span style="font-family:'Free 3 of 9 Extended'; font-size:36pt; border: 1pt solid #000000;">*1234567890*</span>
</body>
</html>

    Proto bych viděl cestu v optimalizaci používaného kódu a vyzkoušet možnosti vložených fontů pomocí CSS3. Možná by bylo cestou i použít pro generování těchto kódu vlastní knihovnu, oprostíte se tak na závislosti na konfiguraci prohlížeče daného uživatele, kdy mu již čárový kód naservírujete třeba jako obrázek.

     
  • 1. června 2011 16:20
     
     
    Přihlásit se a hlasovat
    0
    Dekuji za fcni ukazku v IE9, bohuzel vsak prejit z Quirk modu by znamenalo silenou praci (- je pouzito pro vystupy z aplikace, neni to nejaka verejna jedna stranka publikovana na webu) :-( To nejdriv budu muset vyzkouset nejaky alternativni font. Podobne tak prejit z FONT na IMG - to by uplne zmenilo stavajici technologii - pro distribuci by nestacil samostatny HTML soubor, ale bylo by treba prejit na nejake archivy (MHT, ZIP).
     
  • 1. června 2011 17:45
    Moderátor
     
     
    Přihlásit se a hlasovat
    0

    Teď jsem si s tím několik desítek minut hrál, jelikož nepomohly ani ostatní relativně známé fígle (co znám) ohledně Quirks režimu, které by se projevily i ve výsledném tisku (ve vykreslení ovšem ano), předpokládám, že problém bude nejspíše v samotném vykreslení onoho fontu v rámci IE. Vyzkoušel jsem namátkou jiný barcode font a ten fungoval správně (nicméně obsahoval pomocné EAN znaky). Najit odpovídající nový font či se pokusit upravit v nějakém profesionálním editoru font stávající (pokud neodporuje licenci) bude tedy asi pro vás nejschůdnější cestou.

    Ještě mne tedy napadá cesta generování příslušných html elementů, které by měly nastaveny dané vlastnosti. Počet v závislosti na používaných symbolech. Například formou tabulkových prvků či řádky určených span prvků. Nicméně to by bylo zjevně pracné, ale v nouzi největší proveditelné.

     
  • 1. června 2011 18:53
     
     
    Přihlásit se a hlasovat
    0

    Prave tj. divne, ze ten problem je "jen" v renderu pro tisk, jakoby tam byl nejaky problem v aplikaci vychoziho stylu pro media="print" nebo co. :-( Blbe je, ze to je FONT treti strany, tak muze byt problem i v nem, ale zase ve vsech predchozich verzi IE (snad od IE5, kdy to pouzivame) to fungovalo korektne, az IE9 se k tomu stavi jinak.

    Ono to jde trosku osidit pomoci stylu: ...; DISPLAY: block; MARGIN-TOP: -8mm; MARGIN-BOTTOM: -8mm; kdy je pak ten obsah trochu prizvednuty. To zase naopak vypada blbe v normalnim zobrazenim, ale ten tisk to trochu zkoriguje. Problem ale je, ze ja nevim jake IE ma prijemce/klient toho dokumentu. Tak by se to muselo resit pomoci nejakeho JavaScriptu, ktery az na klientovi a na zaklade typu prohlizece by pripadne modifikoval styl - jestli by se to dalo napsat nejak obecne, ale nevim (to prizvednuti by muselo byt nejak spocitane na zaklade: FONT-SIZE). Oramovani pomoci: "BORDER: solid 1pt black" tam normalne neni, to je dodano jen do ukazky, aby byl videt ten posun/zvetseni zabraneho prostoru - pri pouziti "prizvednuti" bez ohraniceni, to jde umistit vuci textu nad/pod - vypada to nejak takto:

     http://files.cybersoft.cz/Problem-IE9-Code39/test01.htm

     
  • 1. června 2011 19:10
    Moderátor
     
     
    Přihlásit se a hlasovat
    1

    Bohužel tu nemám editor fontů, že bychom se mu podívali na zoubek, nicméně při použití jiného fontu se IE chová korektně.

    A použit samostatné styly pro media print a screen by nebylo možno použít? Případně klasické IF podmínky v zápisu stylu, které následně využije zadaná verze IE.

    <!--[if IE 9]>
    <style> ... </style>
    <![endif]-->

     
  • 1. června 2011 19:58
     
     
    Přihlásit se a hlasovat
    0

    Hmm, to by byla dobra finta!, ale co to zkousim, tak tim, ze tam mame vynuceni: IE=EmulateIE7, tak se to i v IE9 chyta na: "if IE 7" i v IE 9 :-( Jedine to vyhodit, ale to nevim, jestli to nebude mit vedlejsi efekty nekde jinde. Kazdopadne pokud nenajdu upravu fontu, ci jiny font, tak ty podminene styly se jevi, jako nejpouzitelnejsi varianta - zkouska:

    http://files.cybersoft.cz/Problem-IE9-Code39/test02.htm

     
  • 1. června 2011 22:37
     
     
    Přihlásit se a hlasovat
    0
    Tak pri provedeni online konverze pomoci http://www.kirsle.net/wizards/ttf2eot.cgi na EOT je to v IE9 dobre! - viz ukazka: http://files.cybersoft.cz/Problem-IE9-Code39/test03.htm . V IE 8 se to tvari take stejne. Za pouziti zapisu: FONT-FAMILY: BarFontFre3Of9X, Free 3 of 9 Extended Regular; pak snad i ve verzich, ktere vlozene fonty nepodporuji a byly fcni s windows fontem (i kdyz, co se divam, tak EOT snad podporoval uz IE4) nebo kdyby absolutni umisteni EOT souboru nebylo od nekoho dostupne. Zrejme tohle bude nejpouzitelnejsi cesta, pokud do IE9 nedojde nejaka aktualizace (- s cimz moc nepocitam), ktera by render pro print delala stejne jako nizsi verze.
    • Označen jako odpověď MZagora 1. června 2011 22:38
    • Zrušeno označení jako odpověď MZagora 22. listopadu 2011 13:25
    •  
     
  • 1. června 2011 23:13
    Moderátor
     
     
    Přihlásit se a hlasovat
    0
    Jsem rád, že se řešení našlo.
     
  • 22. listopadu 2011 13:41
     
     
    Přihlásit se a hlasovat
    0

    Jeste se k tomu zkusim po delsi dobe vratit. Konverze do EOT fontu je sice castecne reseni, bohuzel vsak neni fcni vsude (u nekoho se musi ve vlastnostech tiskarny nastavit Advanced Printing Features: Disabled, jinak se na strance, kde je EOT font vytiskne bila stranka a pod. :-( ).

    Mezitim jsme prisli na to, ze problem nezpusobuje jen carovy FONT treti strany, ale primo FONTy, ktere jsou soucasti Windows, resp. jejich *CE verze. Viz napr. ukazka: http://files.cybersoft.cz/Problem-IE9-Code39/test05.htm V IE8 zobrazeni+nahled pred tiskem shodne, v IE9 v nahledu pred tiskem verze s *CE fontem uskocena, stejne jako to dela carovy font v 1. ukazce.

    Znovu si tedy myslim, ze se jedna o nejaky problem v IE9, resp. s nejakou soucisnosti s FONTem. Prijde mi to, jako by tam bylo chybne drzeno nejake misto pro diakritiku nebo neco takoveho a carovy font ma stejny priznak jako *CE syst. font, ze se v nem projevuje take...

    Tato ukazka se snad podari nasimulovat vetsimu poctu ozivatelu a kdyby nekdo vedel, jak to potlacit, tak predem dekuji za info!

     
  • 22. listopadu 2011 14:24
    Moderátor
     
     
    Přihlásit se a hlasovat
    0

    Znamena to, ze v EN verzi to nenastane? Jak to vypada v EN+MUI?

    Zkuste jeste problem eskalovat pres mistni Microsoft.

     
  • 22. listopadu 2011 16:11
     
     
    Přihlásit se a hlasovat
    0
    To nevim, jak presne overit... Ja to zatim svadim na IE9 jako takove. Konkretne ja mam treba Win7+IE9 v EN verzi, Czech Language Pack nemam vubec instalovan - i kdyz tim, ze jde doistalovat, tak se jedna asi o MUI verzi...? Ono to s cestinou jako takovou asi nesouvisi, tu jsem dal do prikladu, ze jsem zkousel, jestli bude diakritika zobrazena spravne za pouziti "Arial CE" i "Arial". Chova se to stejne i kdyz tam je text bez jakekoli diakritiky. Nevim ani jaky je rozdil mezi "Arial CE" a "Arial" verzi fontu v dobe unicode, kdyz "Arial" ma taky v sobe ceske znaky. Jestli *CE je jen alias nebo nejaky odkaz na podmozinu znaku? (V C:\Windows\Fonts se zadne *CE fonty nevypisi...) Kazdopadne pouziti *CE verze v nahledu zpusobi to same jako uvodni problem s carovym fontem, jako by v tom fontu byl nejaky priznak, ke kteremu se IE9 chova spatne/jinak.
     
  • 23. listopadu 2011 19:29
     
      Obsahuje kód
    Přihlásit se a hlasovat
    0

    Ještě bych zkusil přímo anglické fórum zabývající se Internet Explorerem

    http://social.technet.microsoft.com/Forums/en-US/ieitprocurrentver/threads
    Obávám se, že pokud je to nějaký bug, tak s ním zde nic neprovedeme.

     
  • 1. prosince 2011 23:06
    Moderátor
     
     
    Přihlásit se a hlasovat
    0

    Chování ověřeno, stejné jako v ukázce.

    Ovšem v Browser Mode IE9 a Document Mode IE9 je v Internet Explorer 9 vše v pořádku, pokud mi nic neuniká. Pokusil bych se tedy skutečně přepsat dokument tak, aby byl validní a funkční pro nejnovější verzi prohlížeče. V případě starších verzí, bych se pak pustil do sekvencí IF-IE.

    Otestujte prosím i v Platform Preview Internet Explorer 10.

     
  • 1. prosince 2011 23:08
    Moderátor
     
     Odpovědět
    Přihlásit se a hlasovat
    0
    Pokud bychom byli schopni tento "bud" rozumně reprodukovat, pak bych byl pro, aby někdo sepsal anglicky use case a dokumentaci k němi a chybu oznámili na Connect. To jest asi to nejrozumnější, co můžeme udělat.
     
  • 1. prosince 2011 23:12
     
     
    Přihlásit se a hlasovat
    0
    V IE 10 ten samý problém...také je to uskočené