hmnc

beidzot sagaidīju atbildi no gMagick izstrādātāja - jā, tādas iespējas nav, un cik nopratu no viņa e-pasta viņš nemaz īsti nesatraucas par jpeg kvalitāti (piedāvāja enchance image, kas ir trokšņu pazemināšana izejas bildei)

marrtins - paldies par palīdzību. alus no manis :) būs laikam kādā brīvākā brīdī jāpārkompilē tas graphicsmagicks.. bet nu jebkurā gadījumā, ja kādam ir ko vēl piebilst - gaidīšu :)

nav diemžēl C iemaņu..to estimatequality cik lasīju tad viņš pats kaut kā aprēķina labākai kvalitātes/performances attiecībai. bet nu par īsu man tie 75 (pietam itkā to konstanti skatoties kvalitāte ir 5. bildes izskatās vairāk uz 5 nekā 75). gd2 izmantojot lietoju 90 (faila svars ir OK un kvalitāte arī apmierinoša. zemāku liekot redzami artefaki). varbūt kaut kur pašam graphicsmagickam var hardcoded to defaulto kvalitāti pamainīt? cik skatījos ir viņam xml konfigurācijas faili, bet nekas saistīts ar jpeg kvalitāti. paldies, ka iedziļinājies :)

vai tiešām 6 gadu laikā 99% topiku joprojām ir palikuši par header erroriem?? :(

par gd2 daudzas reizes ātrāks vismaz uz manas sistēmas. bet nomaiņa notika tāpēc, ka gd2 (svaigākais) nez kāpēc mainīja png krāsu tonalitāti - ļoti ļoti minimāli (praktiski nepamanāmi), bet man tas bija galēji svarīgi. ar gmagick nekas tāds nav novērots. tagad ir doma pāriet vispār uz gmagick, bet redzies - problēma ar jpg...

Sveiki, mēģinu pāriet no gd2 uz GraphicsMagick. (kāpēc ne imagemagick - kaudze ar dependencies, smags, lēnāks, bet tas ir pavisam cits stāsts, ne šoreiz :) ) php pusē lietoju PECL gMagick (http://php.net/manual/en/book.gmagick.php), bet problēma - nekādīgi nevaru uzlikt jpeg kvalitāti, kas man ir par zemu (defaultā stāv 5, ja skatās Gmagick::COMPRESSION_JPEG). funkcijas gmagickam nav (vai neredzu), predefinēto klases constanti nomainīt nemāku (ja to var izdarīt). hardcoded configos uz servera arī īsti neatradu pašam graphicsmagickam kur var nomainīt (bet nu tas tāds ekstrēms variants, vajadzētu tomēr kaut kā kontrolēt to pasākumu caur php skriptu). gmagick izstrādātājs uz meiliem neatbild, googlē atrast nevarēju (varbūt nemācēju). varbūt kāds ir saskāries ar šādu problēmu un varētu izlīdzēt? paldies!

paldies par ieinteresētību! web-veikalu nevajag, vienkārši tas ir labākais un saprotamākais piemērs. ir radušās pāris domas no Alekseja un Kaklz piemēriem - paldies! :)

Kaklz - piemēram ir produkcijas tabula - id, article_id, price, title, description, text title, description un text - katrs savā valodā, bet id, article_id un price ir visiem identisks. katrs tulkojamais lauks atšķirās - nu kā jau normālā tekstā. tevis ieteiktais pirmais variants ir labs pie neliela izmēra tabulām un, ja lauks, kurš jātulko tabulā ir viens - nav jāiespringst uz joiniem vai kādiem sarežģītiem kešošanas mehānismiem. pietam ņem vērā, ka datiem nav tupo inserts un select vienā tabulā, tur iet paralēlie joini vēl ar citām tabulām un dažādas sql darbības, kas strašna palēnina to visu pasākumu.

Klez - izlasi visus postus, šis jau ir aprunāts variants :)

sakarīgs variants, vienīgi katrai tabulai bik ķēpa ar insert/update. ko db eksperti saka par tukšiem text laukiem?

nu tas ir tas mans 3 variants, vienīgi tabula ir unificēta un vienkārši tiek pielikts klāt 'language' parametrs - nav jāizmanto vairākas tabulas vienai produktu tabulai

sapratu par ko aleksejs runā.... neesmu vēl pamodies.. tā ir reāla problēma (ar Alekseja piemēru)...

Kaklz risinājums ir vistuvākais patiesībai, bet ja summārais tabulu ierakstu skaits ir tuvu 50`000. sanāk 4 valodas, kopā tulkojamie lauki ~10. kopā sanāk nevāja tabula ar 2milj ierakstiem. itkā nav tik kosmiski daudz, bet tomēr...

Sveiki, nevaru tikt skaidrībā, kā labāk realizēt daudzvalodu atbalstu saturam, kurš visās valodās ir identisks (piemēram tabula ar cipariem un 'title' lauku.. cipari visās valodās identiski) man ir 3 varianti, no kuriem 2 ir reāli stulbi un viens pietiekami čakarīgs: 1. (lame) vnk tabulā mest klāt piemēram title_lv, title_ru, title_en... fleksibilitāte = 0, valodas ir ierobežotas (grūtības pielikt piemēram vēl 5), problēmas ar lauku skaitu (ja tev ir daudz tulkojamo lauku - title, description, text, ... bla bla bla..) - katram taisīt savu valodu lauku - pašnāvība 2. (json) tajā pašā title laukā (un visos citos) metam iekšā json vai serializētu masīvu ar visām valodām. datubāžu programmētājiem šajā brīdī izkrīt mati... iedomāties to visu datu varzu vienā laukā ir grūti... atrast pēc lauka nav iespējams (ir, bet čakars), datu inserts ir sarežģīts, update ķēpīgs... 3. (multitable) vienīgais variants, ko esmu pielietojis praksē (vēl json nedaudz). 2 tabulas - pirmajā dzenam datus, kas visās valodās ir vienādi, otrajā visus tekstus, savienojam tabulas ar pirmās tabulas id un 'language' parametru.. valodu skaits neierobežots un performanci tas īpaši nebremzē (indeksi rulz). neliela ķēpa ar ievadi/izvadi (defaulto valodu switch, etc), bet tā diezgan tīrs variants. BET - kad tādas multilanguage tabulas ar datiem ir 10... tad tev vajag pretī 10 valodu tabulas - katram savu... sākās problēmas.. nu lūk, tad man jautājums gudrākiem tautiešiem - vai reāli ir vēl kāds variants, līdz kuram man prāts nevelk? vai arī kāda modifikācija no šiem? paldies jau iepriekš

Sveiki, Meklēju flash programmētāju vienam diezgan nopietnam projektam. Projekta pamatbūtība ir lietotāja interaktīvās programmas izveide ar diezgan plašām iespējām. uzreiz brīdinu, ka darbs nav amatieriem. Interesentus lūdzu pieteikties sūtot epastu uz ivars@noepe.lv norādot reāli paveiktos darbus (izskatīsim nevis paveiktos dizainus, bet tieši tehnisko risinājumu), pēctam tiekamies un pārrunājam tehniskās detaļas un finansiālo pusi. Paldies!