Hlavní navigace

Vlákno názorů k článku Grafický metaformát EMF od LO - Jednodušší tiskárny - tzv. GDI printers - NEPOUŽÍVAJÍ...

  • Článek je starý, nové názory již nelze přidávat.
  • 29. 10. 2007 2:40

    LO (neregistrovaný)
    Jednodušší tiskárny - tzv. GDI printers - NEPOUŽÍVAJÍ formát EMF. Jde o tiskárny, které zpravidla umí tisknout jen bitmapy, na což je třeba (například u LED tiskárny, která z hlediska elektroniky v podstatě jen protahuje papír a bliká LED diodami) jen minimum processingu. V driveru má taková tiskárna jako jedinou capability tisk bitmap, a GDI tedy veškeré operace automaticky rastruje do bitmapy. Celkem elegantní postup. Paměť, fonty a procesor už máte v počítači, nač je platit dvakrát?

    K vlastnímu GDI bych řekl, že je veliká škoda, že unixy nic takového nemají. Tedy high-level vrstvu, která aplikaci umožní kreslit na jakémkoliv "povrchu" - do okna, na tiskárnu používající libovolný jazyk, do RDP sessions, na plotter atp. GDI říká driverům, co mají kreslit. Drivery si nastavují capability bits, které říkají, co umí (bitmapu, rectangle, path, bezier curve, rastrování textu, podle konkrétního zařízení). Pokud driver něco neumí, GDI mu věci přeloží (třeba besier curve nebo text vyrastruje do bitmapy, kterou driveru pak pošle). Tenhle skvělý koncept mají Windows dlouhou řadu let, a je základem WYSIWYG ve Windows. V důsledku když se GDI naučí color management, umí ho každá aplikace a každé zařízení.

    Srovnatelnou technologií byl Display Postscript, který ovšem v době vývoje GDI nebyl v použitelné formě (rastrování v nízkých rozlišeních bylo tragické, a u PS to zůstalo problémem až do 90. let), a vyžadoval by vysoké licenční poplatky firmě Adobe (jako každá tehdejší implementace Postscriptu). Pokračovatelem GDI je WPF (Windows Presentation Foundation), část .NET Frameworku 3.0, která staví na pokročilém objektovém API (není problém třeba definovat odraznou plochu, která "sama" odrazí obraz, aplikovat na ní rozvlnění, skriptem na pár řádek měnit parametry toho rozvlnění v reálném čase) a deklarativním jazyku, který skoro-úplně koresponduje s funkcemi API (XPS a XAML, užívané pro popis tiskové stránky, grafiky a UI).
  • 29. 10. 2007 6:47

    Rejpal (neregistrovaný)
    No představ si, že Cairo podporuje paměťové buffery, X11, Win32 GDI, Quartz, BeOS API, OS/2, OpenGL, PNG, PDF, PostScript a SVG...umí GDI generovat už konečně SVG a PDF?
  • 30. 10. 2007 1:28

    LO (neregistrovaný)
    Cairo je wrapper pro pár grafických volání, který neřeší WYSIWYG, správu barevných prostorů, separace, pokročilou typografii... GDI je subsystém, který překládá high level volání pro drivery zařízení, což je poněkud jiné zaměření.

    Proč by proboha GDI mělo generovat SVG nebo PDF? Ono to nemá v popisu práce. Ale můžete si napsat driver zařízení, který píše PDF či SVG. Většina PDF, PS a EPS exportů se ve Windows dělá tímto způsobem.
  • 29. 10. 2007 9:32

    Pavel Tišnovský
    Zlatý podporovatel
    Diky za doplneni. Smichal jsem v jedne vete dva typy tiskaren. Jedny jsou opravdu ty nejjednodussi strojky bez RIPu, ktere chroustaji bitmapy (nekdy i komprimovane). Je to funkcni a dokonce pouzitelne predevsim jako desktopova tiskarna v malem kancliku (jako sitova tiskarna uz moc ne :-). A potom jsou tiskarny, ktere chroustaji nejaky vektorovy format, mezi nimi i EMF.

    Samozrejme jde o to (jak sam pisete), ktere vlastnosti tiskarna podporuje. Pokud napise, ze umi pouze BitBlt (a to jeste bez zrcadleni), tak jsme vlastne na urovni tiskaren chroustajicich bitmapy. Nekdy je problem v tom, ze tiskarna sice hlasi, ze nektere vlastnosti podporuje, ale ve skutecnosti je neumi nebo umi blbe. Jde toto nejak obejit? Opravdu me to zajima, protoze jeden velkoformatovy plotter pri tisku vysrafovanych ploch (tisk pres GDI) misto toho, aby kreslil pouze srafy a na zbytek plochy nesahal, tak vyplni i zbylou plochu cernou (!) barvou. Kdyby to aspon byla bila, tak nic neni videt (krome toho, ze se prepise pozadi, ale to se da obejit, treba prohozenim poradi objektu).

    Jinak koncept "vse pres jedno API", jaky je prezentovan napriklad v GDI (tisk, vystup do souboru, rasterizace, prenos pres schranku) je samozrejme velmi pohodlny, jeho pocatky jsou snad uz nekde v Nextu. I Java API se o neco podobneho snazi ve Swingu, ale stale to neni to prave orechove (a to je napriklad pro me potreby skoda).
  • 30. 10. 2007 2:06

    LO (neregistrovaný)
    Driver tiskárny komunikuje s GDI přes Device Driver Interface. Driver předává GDI seznam svých capabilities ve strukturách DEVINFO (http://msdn2.microsoft.com/en-us/library/ms798627.aspx) a GDIINFO (http://msdn2.microsoft.com/en-us/library/ms798469.aspx). Tedy ono je těch struktur více, ale tyhle dvě jsou pro vás podstatné. Mám za to, že umáznutím capabilites GCAPS_COLOR_DITHER, GCAPS_DITHERONREALIZE a GCAPS_MONO_DITHER by se to mohlo zlepšit. Ale pokud si nechcete hrát pár nocí s debuggerem, tak hoďte driver plotteru na hlavu výrobci, nebo použijte jiný driver.

    Ano, ten koncept "vše přes jedno API" je to, co unixům chybí. Windows, OS/2, Mac i bývalý Next tento koncept mají. U Javy netuším - když pro mě byla aktuální, návrhář dialogů pro Javu měl jen Microsoft, a Java tisknout vůbec neuměla.