Designer – generování obrázků (napojení PHP na grafický program)

Tak jsem to nyní vyzkoušel a našel jsem funkční řešení. V php jsem vygeneroval text do křivky v svg (ne jako text, ale jako křivku, použil jsem třídu EasySVG). Do svg (tedy xml) si navíc vložím atribut, který obsahuje uživatelem zadanou hodnotu na požadovanou šířku. Svg následně otevřu v Illustátoru a skriptem automaticky nastavím požadovanou šířku, která se vezme z atributu přímo z svg. Výsledkem tedy je v Illustrátoru otevřená křivka, stačí dát tisk.Podařilo se mi odstranit i okraj z náhledu, to už je ale komplikovanější a vyžaduje to tabulku pro každý font, o tom jsem již psal (případně vysvětlím). Nicméně otestováno a jedná se o funkční řešení. Výstup zde: http://root.zobrazit.info/svg/Záhada vyřešena, teď už je to jednoduchá práce pro kohokoliv (ale zdlouhavá).

Napsal TomášX;1264551

pro jednu českou společnost nabízející výrobu všemožných reklamních předmětů jsme dělali webový návrhář. Na klientu se náhled vykresloval flashem/javascriptem, o přesnost nám tolik nešlo, stejně nebylo možné finální návrh uzavřít přímo v prohlížeči kvůli nekalibrovaným barvám na monitoru a kvůli různé jemnosti pixelů.

Poptávku z prohlížeči si převzal grafik, jak náhled, tak i jednotlivé vrstvy a jejich vlastnosti, překreslil si to poloautomaticky v grafickém programu (časově cca 15 - 30 min) a předal obchodníkovi, ten kontaktovat zpátky zákazníka, poslal se nějaký vzorek, výroba atd.

Na podobné menší projekty jsme používali qcad, inkscape, libreoffice draw není vůbec špatný, na textury zase krita. Všechny tyhle nástroje lze ovládat přes command line a tedy jednoduše integrovat do aplikací. U posledního projektu, kde generujeme "powerpoint" prezentace používáme html+css a vykreslujeme přes phantomjs.

Moc Vám děkuji z odpověď. Náš problém je opačný - u barev tu přesnost nepotřebujeme naprosto precizní (tedy ve smyslu, že na různých monitorech to člověk může vidět "maličko odlišně"). Pro nás je naopak zásadní ten rozměr. Aktuálně se to řeší stejně, jak uvádíte. Že si to převezme grafik a ručně doupraví, což zabere např. 5 minut, u složitějších 10 minut. Jenomže na tisíc obrázků je to řekněme 7 500 minut, což je nějakých 125 hodin. Potřebujeme to zautomatizovat, aby grafik prováděl pouze "letmou oční kontrolu" a případně vyřadil očividné "šmejdy". Tzn. že kontrola mu zabere maximálně 30 sekund, což oproti 125 hodinám dělá už jen 8 hodin.Ano, command line je skvělá pro napojení, tam pak nic nebrání.---------- Příspěvek doplněn 07.02.2016 v 15:56 ----------

Napsal Jan Stejskal;1264558

Tak jsem to nyní vyzkoušel a našel jsem funkční řešení. V php jsem vygeneroval text do křivky v svg (ne jako text, ale jako křivku, použil jsem třídu EasySVG). Do svg (tedy xml) si navíc vložím atribut, který obsahuje uživatelem zadanou hodnotu na požadovanou šířku. Svg následně otevřu v Illustátoru a skriptem automaticky nastavím požadovanou šířku, která se vezme z atributu přímo z svg. Výsledkem tedy je v Illustrátoru otevřená křivka, stačí dát tisk.

Podařilo se mi odstranit i okraj z náhledu, to už je ale komplikovanější a vyžaduje to tabulku pro každý font, o tom jsem již psal (případně vysvětlím). Nicméně otestováno a jedná se o funkční řešení. Výstup zde: http://root.zobrazit.info/svg/

Záhada vyřešena, teď už je to jednoduchá práce pro kohokoliv (ale zdlouhavá).

Moc děkuji. Díval jsem se na výstup a na první pohled to vypadá dobře. Předpokládám, že totéž by šlo pro parametr height (buďto se zadá šířka nebo výška). Do budoucna plánujeme i možnost zadání šířky i výšky (dojde tedy k deformaci) - předpokládám, že to ale asi není problém? Prostě se uvedenou oba parametry a skript jen upraví velikost. Chápu to totiž tak, že skript v AI prostě přečte daný parametr (nyní "width") a dle něj upraví velikost.S tím "neviditelným" okrajem je jaký problém? Jelikož je to v křivkách, tak tam fakticky žádný okraj není, ne? Přenastavení velikosti by mělo být přesné?Nicméně, jak to bude s efekty? Zakřivení, stíny, textury, atd. (jaké umí např. "canvas")? Nebo ta třída EasySVG to vytváří přímo odsud, dal byste prosím odkaz na tu třídu?

Okraj se týká pouze náhledu, u výsledné křivky žádný není. Ale já bych se s tím náhledem až tak netrápil, těch několik pixelů rozdílu si málokdo všimne. Co se týká nějakých efektů, to je u křivek pro plotr trochu divný požadavek, nicméně v náhledu to realizovat lze (příklad: http://www.w3schools.com/svg/svg_feoffset.asp). Možná existuje i nějaká knihovna s efekty i hotová. "php EasySVG" první odkaz na google, určitě se najdou i jiné, já použil první co jsem našel.

Napsal Jan Stejskal;1264744

Okraj se týká pouze náhledu, u výsledné křivky žádný není. Ale já bych se s tím náhledem až tak netrápil, těch několik pixelů rozdílu si málokdo všimne. Co se týká nějakých efektů, to je u křivek pro plotr trochu divný požadavek, nicméně v náhledu to realizovat lze (příklad: http://www.w3schools.com/svg/svg_feoffset.asp). Možná existuje i nějaká knihovna s efekty i hotová. "php EasySVG" první odkaz na google, určitě se najdou i jiné, já použil první co jsem našel.

Ale pro náhled by šel použít vygenerovaný SVG - ten už je v křivkách, ne? Nebo na ty křivky to převádí až ten AI script společně se změnou velikosti? V náhledu to potíž je, z důvodu, že kolem textu bude ohraničení a u něj kóty udávající rozměry, takže by to nesedělo (on ten okraj není zrovna malý), viz.: 18402S tím plotrem je to samozřejmě nesmysl, tam by efekty kolem být nemohly ... to jsem popletl, jde o tisk fólií speciálním zařízením, nikoliv plotrem.Bojím se, že když to budeme řešit knihovnou pro PHP, dříve či později opět narazíme na problémy (např. textura, větší mezery mezi znaky, větší mezery mezi slovy, větší odsazení mezi řádky, atd.). Pak je tu ještě věc, že po zadání jednoho rozměru potřebujeme získat ten druhý (viz. odkaz na ukázkový designer). V obrázku bude automaticky, ale potřebujeme znát i jeho hodnotu. Tzn. že když zadá šířku, potřebujeme znát i výšku (a naopak).A ještě jedna věc (tu jsem asi zapomněl zmínit nebo zmínil jen částečně), výšku může návštěvník zadat buďto jako absolutní nebo v baseline. A ideálně jako "cap height" (což ale umí máloco a ani AI "cap height" neumí). Tu "cap height" tedy neberme jako nutnost ... to by se dalo případně matematicky přepočítávat.

S tím náhledem bez okraje by to možná šlo řešit i jinak, ale já tam jiné řešení než mít tabulku pro každý font nevidím. Prohlížeč zobrazuje svg vždy na plátně, nejedná se tedy o totožné zobrazení jako v AI.Ta zmíněná knihovna nedělá nic jiného, než že převede svg text na svg křivku. Vše ostatní co tomu předchází je třeba řešit jiným způsobem, možností se určitě najde více (pro canvas nebo i jiné metody).

Napsal Jan Stejskal;1264753

S tím náhledem bez okraje by to možná šlo řešit i jinak, ale já tam jiné řešení než mít tabulku pro každý font nevidím. Prohlížeč zobrazuje svg vždy na plátně, nejedná se tedy o totožné zobrazení jako v AI.

Ta zmíněná knihovna nedělá nic jiného, než že převede svg text na svg křivku. Vše ostatní co tomu předchází je třeba řešit jiným způsobem, možností se určitě najde více (pro canvas nebo i jiné metody).

Nakonec, v tom SVG vlastně ty okraje (vodící čáry) a kóty nebudou, v tom bude jen text o přesné velikosti - ten jediný se tiskne. Ty kóty a vodící čáry budou jen v PNG / JPEG (či "canvas") - v tom, co se zobrazuje na webu (SVG stačí jen vygenerovat a uložit - slouží grafikovi pro tisk). Jde "jen" o to, že text v SVG musí vypadat přesně jako ten zobrazený a rozměrově musí odpovídat. Teď si ale uvědomuju, že to funguje asi jen u absolutního zadání výšky? U baseline to už AI skript nezmění, protože v SVG to už není text, ale křivky a křivka nemá "baseline".A to jsme vyřešili (pokud tedy - co ta baseline?) jen správný rozměr, u všeho dalšího (textura, větší mezery mezi slovy, atd.) jsme tam, kde jsme byli. Také potřebujeme získat druhý rozměr. Nejde o to, že bychom to nedokázali - dokážeme ... ty obrázky, co Vám sem dávám jsou skutečné obrázky z našeho funkčního designeru, který je řešen čistě skrze PHP (GD, Imagick, ...) - ale hodně věcí musíme řešit "vlastními algoritmy" a to je prostě opravdu problém ... není to profesionální, je to složité a problematické na údržbu a rozšiřování. Neustále dokola tak "vymýšlíme kolo", programujeme a řešíme věci, které už někdo (grafický program) dávno vyřešil a umí.Dívám se na: https://github.com/kartsims/easysvg a zdá se, že umí line height a lettering spacing, ale nic dalšího (nějaké "efekty") to už neumí, takže reálně to zřejmě opět nebude použitelné? Nebo mi něco uniká?Ono převod na křivky by mohl jít i skrze "command line", např. skrze Inkscape (nebo možná i ImageMagick):"inkscape image_text.svg --export-text-to-path --export-plain-svg image.svg"Navíc ImageMagick dokáže nabídnout i hodně efektů, je to grafický program jednoduše přístupný skrze "command line". Přijde mi to zatím stále jako lepší řešení než to "bastlit" v PHP, což máme nyní. Ale i zde, jak jsem již uvedl, jsou určitá úskalí.Další věc je, že není asi ideální řešit "zvlášť" PNG / JPEG / CANVAS a zvlášť SVG, protože hrozí, že nebudou stejné. Ale pokud by to bylo v rozumné míře, je možné to řešit i zcela separátně.Níže Vám zasílám ukázku přímo z našeho designeru pro fonty "Script B690" a "Script V730". Dokážete Vámi uváděnou metodou "pomocí kerningu" vytvořit kolem těchto textů těsné ohraničení (klidně může mít každý font specifikované parametry v konfiguračním soboru, musí to ale sedět pro všechny možné velikosti - na stranu druhou, nedají se ty údaje získat přímo z fontu a tedy netřeba je mít uloženy mimo?). My to řešit dokážeme pomocí "vlastního algoritmu". Není to ideální, jsou to prostě okliky, jak něco řešit a kolikrát se objeví něco, co nefunguje, jak má a musí se to řešit.18408184091841018411By the way, to řešení skrze CANVAS/JavaScript se změnou v real-time jste už zcela opustil, tam to tedy nepůjde?Moc Vám děkuji za Váš čas a rady.

Ta cesta, kterou bych preferoval je vytvoření textu na straně klienta se vším všudy (pomocí canvas nebo html+css). Na straně serveru pak výsledek exportovat do svg nebo jiným nástrojem vytvořit totožnou křivku dle nastavení klienta. Zmíněnou php knihovnu jsem použil pouze jako příklad, že to řešit lze, určitě bych ji nebral jako finální produkt.Problém není samotná křivka, to je vyřešené, použije se skript v AI pro automatické nastavení rozměru. Problém je na straně klienta, kdy vykreslení náhledu a to jakoukoliv metodou vytváří okraj, samotný font je tedy vždy o něco menší. A to bych řešil právě tou tabulkou (nezáleží na tom, jakou metodou se náhled vykresluje, okraje způsobuje font samotný, tedy bez ohledu na metodu je okraj vždy stejný pro daný font a daný znak).Nástroj typu AI pro generování náhledu považuji za nepoužitelný. Pokud náhled řešit externě, což bude vždy pomalejší než na straně klienta, pak třeba imagemagic nebo jiný commandline nástroj, ale touto cestou bych nešel nejen z důvodu rychlosti, ale také proto, že zde zůstává problém s okrajem.

Napsal Jan Stejskal;1264845

Ta cesta, kterou bych preferoval je vytvoření textu na straně klienta se vším všudy (pomocí canvas nebo html+css). Na straně serveru pak výsledek exportovat do svg nebo jiným nástrojem vytvořit totožnou křivku dle nastavení klienta. Zmíněnou php knihovnu jsem použil pouze jako příklad, že to řešit lze, určitě bych ji nebral jako finální produkt.

Problém není samotná křivka, to je vyřešené, použije se skript v AI pro automatické nastavení rozměru. Problém je na straně klienta, kdy vykreslení náhledu a to jakoukoliv metodou vytváří okraj, samotný font je tedy vždy o něco menší. A to bych řešil právě tou tabulkou (nezáleží na tom, jakou metodou se náhled vykresluje, okraje způsobuje font samotný, tedy bez ohledu na metodu je okraj vždy stejný pro daný font a daný znak).

Nástroj typu AI pro generování náhledu považuji za nepoužitelný. Pokud náhled řešit externě, což bude vždy pomalejší než na straně klienta, pak třeba imagemagic nebo jiný commandline nástroj, ale touto cestou bych nešel nejen z důvodu rychlosti, ale také proto, že zde zůstává problém s okrajem.

Ten "okraj" je stejný pro stejný font, stejný znak a stejnou velikost fontu - pro jinou velikost fontu je velikost jiná. Chápu správně, že pro zjištění "horního okraje" je potřeba vyhledat "nejvyšší" znak a s těmito daty pak pracovat. Pro "dolní okraj" pak "nejnižší" znak. Pro levý a pravý pak první a poslední znak ALE(!) tady je problém, že u některých fontů, může druhý znak přesahovat první znak (viz. např. u fontů "Script B690" a "Script V730" pro text "ij" bude "j" přesahovat před "i", tudíž pro určení levého okraje bude potřeba pracovat se znakem "j", nikoliv "i", ale tento znak je navíc posunutý doprava o znak "i", který je před ním. A jak to bude v případě "větších mezer mezi znaky", kdy druhý znak bude posunutý ještě o tuto mezeru? Říkám to správně? A jak by se to řešilo v případě, že bude text "prohnutý" nebo "natočený", se stínem, atd.? A to je právě příklad (krom "boundary boxu") dalšího z problémů, o kterém jsem se již zmiňoval.Nejde o to, že to nejde nebo že to nedokážeme řešit - jde to a my to dokážeme, viz. přiložené obrázky, kde vidíte těsné ohraničení. Znovu zopakuji, že jde o to, že najednou řešíte "vlastními skripty" XY problémů, údržba není jednoduchá, rozšíření jsou složitá, hledání chyb a jejich oprava je časově náročná, atd. U použití "externích PHP tříd", apod. - pokud nejde o větší věc, pak hrozí riziko, že autor ukončí vývoj, nebude řešit případné chyby a pro nás to znamená, že objeví-li se problém (a vždy se dříve či později něco objeví), budeme muset problém řešit sami = nastudovat, jak to funguje a vyřešit opravu = desítky hodin času. Stane-li se to vícekrát, jste snadno ve stovkách hodin času. A když se něco řeší v rámci reklamace, je to neproplacený čas. Když to není v rámci reklamace, tak klient nechce platit desítky tisíc za opravy, očekává, že to funguje.Proto to chceme napojit na něco, co to všechno umí - abychom nemuseli tyto dílčí problémy řešit, pouze "předali parametry, co chceme do obrázku vygenerovat". Cestou, kterou popisujete (alespoň zatím) jsme šli na začátku (akorát bez "canvas", čistě s PHP) a po pár letech vývoje a ostrého provozu chceme přejít na sofistikované řešení a vyhnout se tak neustálému řešení výše zmíněného.S ImageMagick (ale už jsem to zmiňoval) se dá velikost řešit vygenerováním vzorového textu na bílé pozadí, poté funkcí (kterou má - tuším trim?) ořezat čistě černý text a poté zjistit šířku / výšky a přepočítat font-size na žádané rozměry. To se mi zdá jako nejlepší a nejrychlejší řešení (na pár řádků kódu). Aktuálně na to máme jiný algoritmus, také funguje, ale je náročnější na údržbu, opravy chyb, atd. A kód je mnohem rozsáhlejší.