Ręczne wytworzenie kompozytowego pdf na potrzeby drukarni
Sebastian Bialy
Nie jestem dobrze obeznany z dtp. Nie na tyle, aby móc jednoznacznie
stwierdzić czy to co chce zrobić ma sens. Jednak pewne okoliczności
spowodowały ze musze rozważyć całkowite złożenie ksiązki pomijając
pośredników[1].
Co mam:
a) Mam plik w wordzie, aczkolwiek to tymczasowe rozwiązanie, docelowo
będzie w xml z którego pośrednio przez xml::fo zrobię pdf.
b) mam drukarnię któa przyjmuje "kompozytowe pdf".
c) chcę całkowity skład tekstu wykonać samodzielnie.
d) nie posiadam oprogramowania "do składu tekstu" typu quark/etc.
Pytania:
1) Czy to w ogóle wykonalne, aby posługując się oprogramowaniem darmowym
wykonać skład tekstu? Zaznaczam, że jestem programistą i wykonanie
pewnych sztuczek, szczególnie na poziomie xml->pdf nie jest problemem.
Nie wymagam (a wręcz nie chcę) dzielenia wyrazów. Możemy założyć, że
jestem w stanie wygenerować dowolnie wyglądającego pdf'a z tego xml'a.
2) Co muszę wiedzieć o "kompozytowym pdf" w szczególności czy
wygenerowanie po prostu zwykłego pdf'a nie załatwie sprawy? Spędziłem
ostatnie 2 godziny dłubiąc w google i mam jakiś taki niejasny wniosek że
kompozytowy pdf to po prostu ... zwykły kolorowy pdf. Mam rację?
3) czy drukarnie nie wymagają jakiegoś dodatkowego elementu na stronach
typu znaczki centrujące, etc ? Nie znam się na dtp i nie chciałbym
rozmawiając z człowiekiem z drukarni dowiedzieć się, że wymagają 4
kółeczek w narożnikach ... bo to oczywiste ....
Zanim zostanie na mnie wylany kubeł pomyj chciałbym zaznaczyć, że powód
[1] wziął się z problemów z pośrenikiem (powiedzmy że natury prawnej)
oraz z faktu że nie jestem zadowolony do końca z efektów. Wydaje mi się,
że nie było by problemów z wykonaniem własnoręcznie takiego składu w
szczególności, że nie zamierzam dzielić wyrazów. Niestety rozmowa z
drukarną kończy się tym, że "wymagamy kompozytowego pdfa" ale próba
uściślenia co mają konkretnie na myśli raczej się nie udaje. Widocznie
muszę być wtajemniczony w biznes ...
Mogę oczywiście doprecyzować potrzeby. Ogólnie mam źródło dokumentu w
xml i mogę wygenerować pdf (choćby fopem) czy cokolwiek innego. Pytanie
czy to wystarczy dla drukarni.
Jeszcze raz przepraszam, że stawiam problem troche nie tak jak robią
fachowcy, ale zmusza mnie do tego sytuacja. Oraz jakieś wewnątrzne
przeświadczenie, że skład tekstu jest raczej zagadnieniem trywialnym
jeśli ma się dobrze przygotowane źródło (u mnie xml).
Tomasz Nowicki
> Nie jestem dobrze obeznany z dtp. Nie na tyle, aby móc jednoznacznie
> stwierdzić czy to co chce zrobić ma sens. Jednak pewne okoliczności
> spowodowały ze musze rozważyć całkowite złożenie ksiązki pomijając
> pośredników[1].
Ja np. zupełnie spokojnie jestem w stanie napisać program komputerowy -
pomijając pośredników. Jednak nie przypuszczam, żeby zrobił to na tyle
dobrze, by chcieć się później tym chwalić. Hint - zmień pośrednika, tzn.
daj to do złożenia komuś, kto robi to zawodowo. Skład książki to nie
tylko kwestia pdf-a, ani też wyłącznie dzielenie (lub nie) wyrazów. Tzn.
- przenoszenia wyrazów.
> Co mam:
>
> a) Mam plik w wordzie, aczkolwiek to tymczasowe rozwiązanie, docelowo
> będzie w xml z którego pośrednio przez xml::fo zrobię pdf.
Jak chcesz się przejechać rowerem, to produkujesz samodzielnie łańcuch i
warzysz towot z oleju sklanego? ;)
> b) mam drukarnię któa przyjmuje "kompozytowe pdf".
I słusznie. Książka jest w pełnym kolorze?
> c) chcę całkowity skład tekstu wykonać samodzielnie.
Jesteś odważny, ale radziłbym nie zaczynać przygody z dtp od składania
książki. Podobnie jak ty, zapewne, nie radziłbyś zaczynać przygody z
programowaniem od pisania aplikacji do układania planu lekcji w niedużej
nawet szkole.
> d) nie posiadam oprogramowania "do składu tekstu" typu quark/etc.
Nie jest to jakiś zasadniczy problem, ale Word akurat nadaje się do
składu książek mniej więcej tak samo, jak Basic do tworzenia
oprogramowania do obsługi baz danych.
> 1) Czy to w ogóle wykonalne, aby posługując się oprogramowaniem darmowym
> wykonać skład tekstu? Zaznaczam, że jestem programistą i wykonanie
W ogóle tak, podobnie jak w zasadzie wykonalne jest upieczenie chleba na
kuchence turystycznej, gdy posiada się tylko patelnię.
> Nie wymagam (a wręcz nie chcę) dzielenia wyrazów. Możemy założyć, że
I to jest błąd, bo tekst zwarty bez przenoszenia wyrazów jest równie
czytelny, co kod programu bez jakichkolwiek komentarzy.
> jestem w stanie wygenerować dowolnie wyglądającego pdf'a z tego xml'a.
Gratuluję, ale naprawdę, skład książki to w najmniejszym stopniu
generowanie pdf. Podobnie, jak programowanie to w najmniejszym stopniu
wybór edytora do pisania kodu.
> 2) Co muszę wiedzieć o "kompozytowym pdf" w szczególności czy
> wygenerowanie po prostu zwykłego pdf'a nie załatwie sprawy? Spędziłem
> ostatnie 2 godziny dłubiąc w google i mam jakiś taki niejasny wniosek że
> kompozytowy pdf to po prostu ... zwykły kolorowy pdf. Mam rację?
Oczywiście - kompozytowy znaczy "nie rozseparowany"
> 3) czy drukarnie nie wymagają jakiegoś dodatkowego elementu na stronach
> typu znaczki centrujące, etc ? Nie znam się na dtp i nie chciałbym
> rozmawiając z człowiekiem z drukarni dowiedzieć się, że wymagają 4
> kółeczek w narożnikach ... bo to oczywiste ....
W kompozytach zwykle nie wymagają - za to wymagają domyślnie paru innych
rzeczy, o których się dowiesz oglądając nie nadające się do niczego
klisze, albo (w najgorszym razie) - wydrukowaną książkę w drodze na
makulaturę.
> Zanim zostanie na mnie wylany kubeł pomyj chciałbym zaznaczyć, że powód
Zaraz tam pomyj - co drugi dzień trafiają tu tacy łowcy przygód :D
> uściślenia co mają konkretnie na myśli raczej się nie udaje. Widocznie
> muszę być wtajemniczony w biznes ...
Drukarnia zachowuje się kulturalnie, bo trzeba jakoś zasugerować
klientowi, że się nie zna i że powinien zlecić robotę fachowcowi, a nie
wypada powiedzieć mu tego wprost...
> Mogę oczywiście doprecyzować potrzeby. Ogólnie mam źródło dokumentu w
> xml i mogę wygenerować pdf (choćby fopem) czy cokolwiek innego. Pytanie
> czy to wystarczy dla drukarni.
Zapytaj tam właśnie - powtarzam, skład książki to nie tylko strona
komputerowo-techniczna, a nawet zgoła co innego.
> Jeszcze raz przepraszam, że stawiam problem troche nie tak jak robią
> fachowcy, ale zmusza mnie do tego sytuacja. Oraz jakieś wewnątrzne
> przeświadczenie, że skład tekstu jest raczej zagadnieniem trywialnym
> jeśli ma się dobrze przygotowane źródło (u mnie xml).
Trywialne to jest zamiatanie schodów pod górę. Skład to taka sama
dziedzina wiedzy, jak programowanie - ma swoje zasady, metody, pułapki i
niepodzianki. Dla fachowca to pestka i codzienna nuda - dla ciebie -
ciemny las. Nie wiedząc nic o tym, narażasz się na masę ciężkiej, nikomu
nie potrzebnej roboty, zmarnujesz czas i pieniądze (bo za druk musisz
zapłacić niezależnie od efektu)
T.
Sebastian Bialy
> Ja np. zupełnie spokojnie jestem w stanie napisać program komputerowy -
> pomijając pośredników. Jednak nie przypuszczam, żeby zrobił to na tyle
> dobrze, by chcieć się później tym chwalić.
Dokładnie z tego powodu nie zamierzam się tym chwalić.
> Hint - zmień pośrednika, tzn.
> daj to do złożenia komuś, kto robi to zawodowo. Skład książki to nie
> tylko kwestia pdf-a, ani też wyłącznie dzielenie (lub nie) wyrazów. Tzn.
> - przenoszenia wyrazów.
Hmm a co dodatkowo ? Zaznaczam, że wygląda samego dokumentu przygotowuję
samodzielnie. Czy poza dodtkowym podziałem wyrazów w końcowym wydruku
można znaleźć coś jeszcze ? Czy chodzi np. o przygotowanie palety tak
aby wyglądała sensownie?
>> a) Mam plik w wordzie, aczkolwiek to tymczasowe rozwiązanie, docelowo
>> będzie w xml z którego pośrednio przez xml::fo zrobię pdf.
> Jak chcesz się przejechać rowerem, to produkujesz samodzielnie łańcuch i
> warzysz towot z oleju sklanego? ;)
Tak, ponieważ ta książka jest bardzo rózna od typowych książek:
konkretnie posiada bardzo dużo odsyłaczy nad którymi muszę zapanować w
sposób którego nie posiadają biurowe edytory tekstu. Ponadto częśc
elementów ksiązki jest generowanych. Nie sposób ich zapisać "raz a
dobrze w wordzie". To skomplikowana sprawa. Mówiąc skrótowo: nie jest to
książka pisana przez humanistę.
> I słusznie. Książka jest w pełnym kolorze?
Toretycznie tak. Praktycznie pierwszy wydruk dopuszczam w odcieniach
szarości. Kolor zostawiam na później, choć jeśli okaże się, że nie
wyjdzie jakoś przerażająco drogo to kto wie. Ogólnie nie zamykam drogi
do pełnego koloru - być może.
>> c) chcę całkowity skład tekstu wykonać samodzielnie.
> Jesteś odważny, ale radziłbym nie zaczynać przygody z dtp od składania
> książki.
Nie widze różnicy pomiędzy składaniem jednej strony A4 a 500 stron
ksiązki - mam na myśli technikę. Ilość nie ma znaczenia tym bardziej że
mechanizmy składania w 99% dostarczam samodzielnie i jest on skalowalny
do dowlonych rozmiarów.
>> d) nie posiadam oprogramowania "do składu tekstu" typu quark/etc.
> Nie jest to jakiś zasadniczy problem, ale Word akurat nadaje się do
> składu książek mniej więcej tak samo, jak Basic do tworzenia
> oprogramowania do obsługi baz danych.
Word jest _wymczasowy_. Nazwijmy go po prostu edytorem tekstu. Skład
wykonać mogę (i docelowo wykonam) w xml->pdf.
>> 1) Czy to w ogóle wykonalne, aby posługując się oprogramowaniem
>> darmowym wykonać skład tekstu? Zaznaczam, że jestem programistą i
>> wykonanie
> W ogóle tak, podobnie jak w zasadzie wykonalne jest upieczenie chleba na
> kuchence turystycznej, gdy posiada się tylko patelnię.
Rozumiem, że bez zainwestowania pieniędzy moje literki w książce będą
wyglądały jakoś zasadniczo inaczej? Jakie konkretnie problemy będę mógł
zaobserwować w wynikowym dokumencie?
>> Nie wymagam (a wręcz nie chcę) dzielenia wyrazów. Możemy założyć, że
> I to jest błąd, bo tekst zwarty bez przenoszenia wyrazów jest równie
> czytelny, co kod programu bez jakichkolwiek komentarzy.
O to świetnie, bo widzisz jesli w kodzie programu są komentarze, to
widocznie programista musiał coś niezrozumiałego skomentować. Ja
preferuje kod czytelny sam z siebie. A wracając do tematu - dziwnym
trafem szybciej czytam tekst bez przenoszonych wyrazów niż z. To kwestia
gustu i akurat nie zamierzam się upierać nad przenoszeniem bo mi (i paru
ludziom z mojego otoczenia również) przenoszenie wyrazów przeszkadza niż
pomaga.
>> jestem w stanie wygenerować dowolnie wyglądającego pdf'a z tego xml'a.
> Gratuluję, ale naprawdę, skład książki to w najmniejszym stopniu
> generowanie pdf. Podobnie, jak programowanie to w najmniejszym stopniu
> wybór edytora do pisania kodu.
O to ciekawa teoria. Wobec tego zakładając że:
a) mogę uzyskać dowolny wygląd końcowego dokumentu pdf (wszelkie
elementy graficzne zostają wygenerowane w transformacji xml->pdf),
b) mogę dostarczyć wynik w paru formatach w tym "zwykłym pdf" bądz
dowolnie rozseparowanym na dowolny model koloru,
to co nam jeszcze pozostaje ze "składu tekstu" ? To jest całkiem serio
pytanie.
Zapomniałem wspomnieć, że 90% rysunków to rysunku sztuczne - schematy na
ten przykład. Zdjęc nie będzie praktycznie w ogóle.
> Oczywiście - kompozytowy znaczy "nie rozseparowany"
Ah. Czyli po prostu pdf. Chyba że jesli dobrze doczytuje z internetu:
niekiedy należy go jednak rozseparować na CMY(K)?
> W kompozytach zwykle nie wymagają - za to wymagają domyślnie paru innych
> rzeczy, o których się dowiesz oglądając nie nadające się do niczego
> klisze, albo (w najgorszym razie) - wydrukowaną książkę w drodze na
> makulaturę.
Gdzie mogę znaleźć informacje o tych "problemach"? Własnie to interesuje
mnie najbardziej.
> Drukarnia zachowuje się kulturalnie, bo trzeba jakoś zasugerować
> klientowi, że się nie zna i że powinien zlecić robotę fachowcowi, a nie
> wypada powiedzieć mu tego wprost...
"Fachowcy" robią strasznie skomplikowaną rzecz: dostają _pięknie_
wyglądający dokument w wordzie z wzorowymi stylami. I generują pdf.
Jesli robią coś pomiędzy to chciałbym wiedziec co takiego. Zakładam dla
bezpieczeństwa, że mamy druk w odcieniach szarości.
> Zapytaj tam właśnie - powtarzam, skład książki to nie tylko strona
> komputerowo-techniczna, a nawet zgoła co innego.
Problem w tym, że gdzie bym nie rzucił się googlem to ciągle o tym
słysze, ale żadnego konkretu. Ponawiam pytanie: gdzie można o tym
poczytać bez zbędnego nadęcia ze strony "mistszuf dtp". Choćby tylko po
to aby zarzucić ten pomysł. Bo przeciez nie zamierzam tego robic, jesli
to niewykonalne.
> ciemny las. Nie wiedząc nic o tym, narażasz się na masę ciężkiej, nikomu
> nie potrzebnej roboty, zmarnujesz czas i pieniądze (bo za druk musisz
> zapłacić niezależnie od efektu)
O ile okaże się, że to niewykonalne to bez watpienia zapłacę fachowcowi
za Open&Save w quarku. Jednak zanim to zrobie chciałbym wiedzieć co
takiego niezykle trudnego pomiędzy się dzieje. I czy aby na pewno wymaga
to quarka/whatever.
Wiem, że to co pisze w oczach DTPowców jest może i śmieszne, jednak
pozwole sobie być upartym w dążeniu do wiedzy. Może się okazać, że nie
taka ona straszna.
Marek Włodarz
Sebastian Bialy napisał(a):
> Nie jestem dobrze obeznany z dtp. Nie na tyle, aby móc jednoznacznie
> stwierdzić czy to co chce zrobić ma sens. Jednak pewne okoliczności
> spowodowały ze musze rozważyć całkowite złożenie ksiązki pomijając
> pośredników[1].
OK, masz zapewne powody.
> Co mam:
>
> a) Mam plik w wordzie, aczkolwiek to tymczasowe rozwiązanie, docelowo
> będzie w xml z którego pośrednio przez xml::fo zrobię pdf.
Mam dziwne wrażenie, że drzewa przesłoniły ci las.
[ciach resztę]
Otóż - co już ci powiedziano - wygenerowanie PDF (albo Postscriptu,
albo cokolwiek innego) to kwestia czysto techniczna i na pewno nie
stanowi problemu.
Natomiast skład książki - to jakby zupełnie inna rzecz. W dwóch
słowach, czy nawet w dwustu, niestety nie da się tego streścić. Ale
w telegraficznym skrócie chodzi o takie rzeczy, jak:
Kompozycja (w szerokim znaczeniu) - zarówno najogólniejsza, czyli
właściwe zaprojektowanie marginesów, dobranie właściwych czcionek dla
poszczególnych elementów tekstu, odpowiednich proporcji itp., jak
i szczegółowa. Tego się trzeba po prostu nauczyć i raczej nie da się
tego wyłożyć w kwadrans. Ani w tydzień. Może w rok.
Właściwe prowadzenie tekstu (kerning, wyrównanie świateł, utrzymanie
registru itp.) - programy do składu potrafią to zrobić, edytory tekstu
raczej nie, a co do opisywanego przez ciebie narzędzia do tworzenia
PDF z XML - niemal _na pewno_ nie. No, chyba że to jest jakiś godny
następca TeX-a. Ale w to wątpię.
Przestrzeganie ogólnie ustalonych reguł dla składu książek.
Oczywiście, to nie jest obowiązek narzucony prawem (choć w pewnym
sensie jest, bo reguluje to polska norma) - nikt nie zamknie nikogo
w więzieniu za błędy składu. Ale też mała jest szansa, że ktoś taką
książkę będzie chciał czytać.
Na temat niedzielenia wyrazów i argumentu, że dzielenie przeszkadza -
jest to dla mnie absolutna nowość, jako że wszystkie chyba znane
badania na ten temat głoszą coś dokładnie odwrotnego. Szczególnie
dotyczy to języka polskiego, w którym występuje stosunkowo dużo
"długich" wyrazów.
Mogę się założyć o cokolwiek, że - przy takich założeniach i
nastawieniu - wytworzony przez ciebie skład będzie być może dawał się
czytać, ale na pewno nie będzie estetyczny...
Zaś co do potencjalnych problemów technicznych, to imię ich milion.
I naprawdę nie podejmuję się przewidzieć, co tam się może trafić - bo
może wszystko - od źle drukujących się znaków, przez nieoczekiwane
podstawienia, znikanie pewnych elementów lub pojawianie się
niechcianych, aż po rozseparowanie czarnego tekstu na wszystkie
składowe... żeby wymienić tylko kilka na starcie. A przede wszystkim
istnieje wcale niemałe prawdopodobieństwo, że PDF co prawda da się
obejrzeć i wydrukować na drukarce, ale np. nie uda się go naświetlić...
Skoro jesteś - jak mi się wydaje - programistą - przyjrzyj się
TeX-owi. I tak zmierzasz "pod drodze" przejść przez format
pośredniczący - czy to będzie XML, czy co innego, nie ma większego
znaczenia. Zapewne istnieją już makra do LaTeXa, które pozwalają małym
(stosunkowo) wysiłkiem obsłużyć XML - zapytaj na "siostrzanej" grupie
pl.comp.dtp.tex.
TeX przynajmniej zagwarantuje ci przyzwoity wygląd końcowy oraz
poprawność techniczną uzyskanych plików. Przy czym ten "przyzwoity"
należy rozumieć jako "prawie najlepszy z możliwych".
Pozdrawiam,
Marek W.
--
FAQ grupy pl.comp.dtp: http://dtp.art.pl/
Lista mirrorów: http://emide.neostrada.pl
"Nie pracuje dobrze ten, kto z zamiarem wykonania łopaty buduje rakietę."
Stanisław Lem.
Tomasz Szafranowski
wiadomości news:slrn.pl.f0lj...@marekw.home...
> W artykule <eue8r1$s7k$1...@atlantis.news.tpi.pl>
>[ciach na całość]
Ot, mądrego dobrze posłuchać :-)
Panie Marku, dziękuję. 90% posta będę czytał klientom (niektórym).
Pozdrawiam
--
Tomasz Szafranowski
www.zpfilip.pl
Sebastian Bialy
> Mam dziwne wrażenie, że drzewa przesłoniły ci las.
Bardzo możliwe. Tylko że u mnie te drzewa to dość istotny składnik lasu ...
> Kompozycja (w szerokim znaczeniu) - zarówno najogólniejsza, czyli
> właściwe zaprojektowanie marginesów, dobranie właściwych czcionek dla
> poszczególnych elementów tekstu, odpowiednich proporcji itp., jak
> i szczegółowa. Tego się trzeba po prostu nauczyć i raczej nie da się
> tego wyłożyć w kwadrans. Ani w tydzień. Może w rok.
To _nie jest_ problem ponieważ jak dobrze rozumiem jesli wykonam sobie
wydruk próbny to nie będzie zasadniczej różnicy w akurat tych
elementach. Więc argument że zobacze to dopiero z drukarni nie ma sensu.
_Chyba_ że wydruk z drukarni jest zasadniczo różny od wydruku na
przeciętnej laserówce. Wtedy rzeczywiście to jest problem. Jednak
trzymając w ręku przygotowany wydruk i ksiązkę nie dostrzegam
specjalnych różnic w wyglądzie dowolnych elementów.
Pozwole sobie więc powiedziec, że ewentualny problem to kwestia gustu i
jak najbardziej do przeskoczenia z mojej strony.
> Właściwe prowadzenie tekstu (kerning
Chodzi o słynne "fi" w Tex ?
>, wyrównanie świateł,
Chodzi o standardowe metody analizy obrazu normalizujace histogram
obrazu? (tak mi wynika z google).
> utrzymanie
> registru itp.)
Chodzi o zwykłe wyrównanie w pionie przez rozciągnięcie?
> - programy do składu potrafią to zrobić, edytory tekstu
> raczej nie, a co do opisywanego przez ciebie narzędzia do tworzenia
> PDF z XML - niemal _na pewno_ nie. No, chyba że to jest jakiś godny
> następca TeX-a. Ale w to wątpię.
Może wątpić, a ja tylko delikatnie wspomnę, że o ile mogę sobie bez
kłopotu zrobić xml->pdf to równie bez kłopotu mogę sobie zrobić
xml->tex. Xml to powiedzmy taki mój sposób prywatny trzymania treści i
logicznego jej podziału. Jeśli kerning jest kluczowy to nie ma problemu
zrobie xml->tex->pdf i będzie. Pozostałe bajery mogę zrobić również
automatycznie bądź półautomatycznie.
> Przestrzeganie ogólnie ustalonych reguł dla składu książek.
Hmmm. Są gdzieś spisane? Mam nadzieję, że nie znajdę tam haseł typu
"spis treści piszemy fontem xxx, w odstępie 1.654mm, z kropkami
wiodącymi ... etc" bo to akurat też kwestia gustu i estetyki którą można
samodzielnie wypracować dla danej ksiązki.
> Na temat niedzielenia wyrazów i argumentu, że dzielenie przeszkadza -
> jest to dla mnie absolutna nowość, jako że wszystkie chyba znane
> badania na ten temat głoszą coś dokładnie odwrotnego. Szczególnie
> dotyczy to języka polskiego, w którym występuje stosunkowo dużo
> "długich" wyrazów.
Jest to kwestia gustu. Tak przy okazji - dzielenie wyrazów nie jest
trywialne ale wykonalne. Na tyle jednak niewygodne technicznie, że nie
wiem czy aby na pewno warto je stosować. Nie jest w moim mniemaniu
istotnym elementem.
> Mogę się założyć o cokolwiek, że - przy takich założeniach i
> nastawieniu - wytworzony przez ciebie skład będzie być może dawał się
> czytać, ale na pewno nie będzie estetyczny...
Tutaj znowu pytanie czy estetyka jest podstawowym założeniem i czy
akurat dzielenie wyrazów jest tak kluczowe dla estetyki.
> może wszystko - od źle drukujących się znaków, przez nieoczekiwane
Dlaczego mają się źle drukować? Tak z ciekawości co mnie może czekać:
np. literka A nie będzie miała poprzeczki w jakimś-tam-foncie? Hmmm...
czy to aby nie jest problem drukarni ocenić to wstępnie? Bo nie uwierzę,
że miszczowie od DTP dają plik i modlą się żeby coś nie znikło.
> podstawienia
co to ?
>, znikanie pewnych elementów lub pojawianie się
> niechcianych
W jaki sposób może się z nienacka coś pojawić? Czy masz na myśli np.
smugi na gradiendach? To jeszcze jestem w stanie zrozumieć, ale jeśli
powiesz mi że pojawiają się przypadkowe linie, punkty itd na pustej
przestrzeni to będę co najmniej zdziwiony.
>, aż po rozseparowanie czarnego tekstu na wszystkie
> składowe...
Nawet jesli tekst będzie czarny np. R=0,G=0,B=0 albo C=0,M=0,Y=0,K=100%
? To już mi pachnie błędem drukarni. Zwracam uwagę że dokument PDF
będzie _perfekcyjny_ bo stworzony automatycznie. Nie ma tam błędów typu
"prawie czarny tekst".
> istnieje wcale niemałe prawdopodobieństwo, że PDF co prawda da się
> obejrzeć i wydrukować na drukarce, ale np. nie uda się go naświetlić...
Hmmm... bo ? Zły format ? Zły rozmiar ? Przeciez wszystko jest
konfigurowalne.
Tak na marginesie: jesli okaże się ze problemem będzie rozmiar to zmiana
rozmiaru to jakieś 20 sekund. Automatyka zadba o ponowny skład w/g
nowych norm.
> Skoro jesteś - jak mi się wydaje - programistą - przyjrzyj się
> TeX-owi. I tak zmierzasz "pod drodze" przejść przez format
> pośredniczący - czy to będzie XML, czy co innego, nie ma większego
> znaczenia. Zapewne istnieją już makra do LaTeXa, które pozwalają małym
> (stosunkowo) wysiłkiem obsłużyć XML - zapytaj na "siostrzanej" grupie
> pl.comp.dtp.tex.
Widzisz. Ja jestem gatunkiem człowieka który zanim użyje narzędzia
najpierw weźmie go pod lupę. Jak wiem, że tex ma ogromną liczbę
fanatycznych wyznawców na świecie. Z wieloma rozmiawiałem i wiem że są
zrobieni ze zbrojonego betonu. Problem w tym że trudno mi sobie
wyobrazić gorszą technologię do tworzenia _mojego_ dokumentu niż tex. Ma
obleśną (żeby nie powiedziec debilną) składnię i nie ma separacji treści
od wyglądu (tzn ma ale nikt tak w tex nie pisze). Dlatego źródło mam w
xml bo on mi to _zapewnia_ i jest wygodnie i łatwo parsowalny.
Przypominam że jestem programistą, a więc jestem nienormalny z
definicji, dostrzegając problemy tam gdzie dla innych jest wszystko ok.
A nie jest to również ksiązka w normalnym tego słowa znaczeniu. Np. w
treści znajdują się źródła rysunków które podczas składu automagicznie
kompilują się do plików graficznych. Tex jest do tego bardzo niewygodny.
Bez względu na problemy nie będzie on moją platformą podstawową zapewne
_nigdy_.
Tex tak, ale jako warstwa pośrednia pomiędzy xml a ksiązką. I tylko
jesli to jest niezbędne.
> TeX przynajmniej zagwarantuje ci przyzwoity wygląd końcowy oraz
> poprawność techniczną uzyskanych plików. Przy czym ten "przyzwoity"
> należy rozumieć jako "prawie najlepszy z możliwych".
Poprawnośc techniczną zapewni mi każda metoda generacji wyglądu w sposób
automatyczny w tym i mój xml->whatever->pdf.
wlodarz@swallowmy.cum blue taxi
jesz kupy?
zdajesz sobie sprawe, ze twoja matka to
zwykla zdzira ktora daje dupy kazdemu
kto do niej sie usmiechnie?
blue taxi
--
alt.pl.dupa
humor hermetyczny (c)nuria
Lolalna Loja
>> 2) Co muszę wiedzieć o "kompozytowym pdf" w szczególności czy
>> wygenerowanie po prostu zwykłego pdf'a nie załatwie sprawy? Spędziłem
>> ostatnie 2 godziny dłubiąc w google i mam jakiś taki niejasny wniosek
>> że kompozytowy pdf to po prostu ... zwykły kolorowy pdf. Mam rację?
>
> Oczywiście - kompozytowy znaczy "nie rozseparowany"
Jedno "ale" - jak znam życie to "zwykły kolorowy" pdf puszczony z xmla
lub worda będzie w przestrzeni barwnej RGB. A kolega najwyraźniej
potrzebuje CMYKa i odpowiednich rozdzielczości.
Loja
--
*Majkel, ty to ale jestes!*
Lolalna Loja
> Wydaje mi się,
> że nie było by problemów z wykonaniem własnoręcznie takiego składu w
> szczególności, że nie zamierzam dzielić wyrazów. Niestety rozmowa z
> drukarną kończy się tym, że "wymagamy kompozytowego pdfa" ale próba
> uściślenia co mają konkretnie na myśli raczej się nie udaje. Widocznie
> muszę być wtajemniczony w biznes ...
Lol. Wyobraź sobie, że dzwonisz do mnie i żądasz przygotowania kodu do
strony. A ja Cię pytam co to jest kod i "proszę mi wyjaśnić jak to się
pisze". Miałbyś niezłą polewkę pewnie? ;)
> Jeszcze raz przepraszam, że stawiam problem troche nie tak jak robią
> fachowcy, ale zmusza mnie do tego sytuacja. Oraz jakieś wewnątrzne
> przeświadczenie, że skład tekstu jest raczej zagadnieniem trywialnym
> jeśli ma się dobrze przygotowane źródło (u mnie xml).
Fatalne przeświadczenie. Na druku i składzie znasz się mniej więcej tak
jak ja na skryptach. Nie znasz najbardziej podstawowych podstaw i tu
moja naprawdę niezłośliwa rada - nie bierz się za to, bo umoczysz jak w
banku. Choćbyśmy nie wiem jak chcieli nie jesteśmy Ci w stanie przez
grupę przekazać wiedzy, którą zdobywaliśmy przynajmniej miesiącami (a co
poniektórzy latami) - jest tego trochę a większość trudno na odległość
przekazać komuś, kto nie ma o tym nawet zielonego pojęcia. Wybacz
szczerość, ale na obecną chwilę nie jesteś w stanie wykonać tej pracy.
Poszukaj kogoś, kto zna chociaż podstawy...
Sebastian Bialy
> jesz kupy?
Ponieważ nie bywam na tej grupie regularnie to pytanie: Czy mam
przyjemnośc z jakimś lokalnym debilem, czy też to jakiś odosobniony
przypadek neostradowy ?
Lolalna Loja
> To _nie jest_ problem ponieważ jak dobrze rozumiem jesli wykonam sobie
> wydruk próbny to nie będzie zasadniczej różnicy w akurat tych
> elementach. Więc argument że zobacze to dopiero z drukarni nie ma sensu.
Rany...
> _Chyba_ że wydruk z drukarni jest zasadniczo różny od wydruku na
> przeciętnej laserówce.
Jest. I nie tylko to jest problemem. Uwierz nam.
> trzymając w ręku przygotowany wydruk i ksiązkę nie dostrzegam
> specjalnych różnic w wyglądzie dowolnych elementów.
Zobaczysz, zobaczysz...
> Chodzi o standardowe metody analizy obrazu normalizujace histogram
> obrazu? (tak mi wynika z google).
Nie.
> > utrzymanie
> > registru itp.)
>
> Chodzi o zwykłe wyrównanie w pionie przez rozciągnięcie?
Nie.
> Jest to kwestia gustu.
Nie.
> Tak przy okazji - dzielenie wyrazów nie jest
> trywialne ale wykonalne. Na tyle jednak niewygodne technicznie, że nie
> wiem czy aby na pewno warto je stosować. Nie jest w moim mniemaniu
> istotnym elementem.
Wpisywanie <body> na początku pliku HTML jest trywialne i nie jest moim
zdaniem istotnym elementem.
> Tutaj znowu pytanie czy estetyka jest podstawowym założeniem i czy
> akurat dzielenie wyrazów jest tak kluczowe dla estetyki.
Jest.
> > może wszystko - od źle drukujących się znaków, przez nieoczekiwane
>
> Dlaczego mają się źle drukować?
Bo może być problem z ripowaniem czcionek, zwłaszcza przy starszych
sterownikach.
> Tak z ciekawości co mnie może czekać:
> np. literka A nie będzie miała poprzeczki w jakimś-tam-foncie?
Będziesz miał krzaczki albo puste miejsca zamiast polskich znaków,
posypią Ci się odległości między znakami, będzie bold tam gdzie go nie
wpisywałeś... itd, itp...
> czy to aby nie jest problem drukarni ocenić to wstępnie?
Nie.
> Bo nie uwierzę,
> że miszczowie od DTP dają plik i modlą się żeby coś nie znikło.
Uwierz.
> W jaki sposób może się z nienacka coś pojawić?
Np. coś jest ukryte, ale rip to widzi.
> Czy masz na myśli np.
> smugi na gradiendach? To jeszcze jestem w stanie zrozumieć, ale jeśli
> powiesz mi że pojawiają się przypadkowe linie, punkty itd na pustej
> przestrzeni to będę co najmniej zdziwiony.
Dużo zdziwień jeszcze przed Tobą ;)
> Nawet jesli tekst będzie czarny np. R=0,G=0,B=0 albo C=0,M=0,Y=0,K=100%
Nie albo. Musi być CMYK. Jak zrobisz w RGB to Cię drukarnia wyśle na drzewo.
> ? To już mi pachnie błędem drukarni.
Nie. Oni robią tak, jak mają w pliku. I nic sami z tym nie zrobią, nawet
gdyby chcieli.
> Zwracam uwagę że dokument PDF
> będzie _perfekcyjny_ bo stworzony automatycznie.
ROTFL
> Hmmm... bo ? Zły format ? Zły rozmiar ? Przeciez wszystko jest
> konfigurowalne.
Bo nie masz pojęcia nawet o tym jakie błędy możesz popełnić i za bardzo
ufasz swojej intuicji ;)
> Tak na marginesie: jesli okaże się ze problemem będzie rozmiar to zmiana
> rozmiaru to jakieś 20 sekund. Automatyka zadba o ponowny skład w/g
> nowych norm.
ROTFL 2.
> Przypominam że jestem programistą, a więc jestem nienormalny z
> definicji, dostrzegając problemy tam gdzie dla innych jest wszystko ok.
Ja tam widzę, że wręcz przeciwnie - wszyscy Ci mówią, że nie masz
pojęcia a Ty idziesz w zaparte ;)
> A nie jest to również ksiązka w normalnym tego słowa znaczeniu. Np. w
> treści znajdują się źródła rysunków które podczas składu automagicznie
> kompilują się do plików graficznych.
Oczywiście wszystkie są w RGB i mają 72 dpi? ;)
> Tex jest do tego bardzo niewygodny.
> Bez względu na problemy nie będzie on moją platformą podstawową zapewne
> _nigdy_.
Kup Adobe ;)
> Poprawnośc techniczną zapewni mi każda metoda generacji wyglądu w sposób
> automatyczny w tym i mój xml->whatever->pdf.
Ręce mnie byli opadli :)
Sebastian Bialy
> Lol. Wyobraź sobie, że dzwonisz do mnie i żądasz przygotowania kodu do
> strony. A ja Cię pytam co to jest kod i "proszę mi wyjaśnić jak to się
> pisze". Miałbyś niezłą polewkę pewnie? ;)
Zależy. Jeśli mógłbym znaleźć pojęcie "kodu strony" na milionie stron w
internecie do bym d... nie zawracał komukolwiek w drukarni. Problem w
tym, że co do "kompozytowego pdf" to mam jakieś 10 definicji w google i
każda inna. Świadczy to o tym, że wiedza z zakresu dtp jest średnio
usystematyzowana. Czytając posty nie tylko polskie ale _w ogóle_ mam
wrażenie że każdy jest ekspertem tylko każdy inaczej. Dlatego pytam u
źródła licząc na odpowiedź ścisłą typu: "kompozytowy pdf to zwykły pdf".
I prawie taką otrzymałem ;)
> Na druku i składzie znasz się mniej więcej tak
> jak ja na skryptach. Nie znasz najbardziej podstawowych podstaw i tu
> moja naprawdę niezłośliwa rada - nie bierz się za to, bo umoczysz jak w
> banku.
Hmm... jak na razie po poście Marka Włodarza nie wystraszyłem się. Z
grubsza widzę że jeśli odrzuci się pierdoły o wielkościach marginesów i
czcionkach które są absolutnie nieznaczące technicznie to pozostaje
tylko problem "jakiś zniekających elementów tekstu" co do których nie
mam pewności gdzie i dlaczego mają znikać. Tu przyznaje, że moja wiedza
jest poniżej dna, jednak coś mi mówi, że technologia od czasów
wynalezienia druku chyba się nieco polepszyła i aż tak źle nie jest
żebym miał dokumencie jedno a na wydruku co innego w sposób zasadniczy.
> Choćbyśmy nie wiem jak chcieli nie jesteśmy Ci w stanie przez
> grupę przekazać wiedzy, którą zdobywaliśmy przynajmniej miesiącami (a co
> poniektórzy latami) - jest tego trochę a większość trudno na odległość
> przekazać komuś, kto nie ma o tym nawet zielonego pojęcia.
Jeśli to wiedza z zakresu estetyki to nie chce jej. Bo będzie od razu 15
opini na 10 grupowiczów. Jesli to wiedza techniczna (np dotyząca
możliwości technicznych maszyn) to jestem bardzo zainteresowany bo tej
właśnie szukam.
> Wybacz
> szczerość, ale na obecną chwilę nie jesteś w stanie wykonać tej pracy.
> Poszukaj kogoś, kto zna chociaż podstawy...
Hmmm... a gdzie znajdę te podstawy chociaż troche spisane tak aby ocenić
czy są faktycznie aż tak niezwykle zagmatwane.
Lolalna Loja
> O ile okaże się, że to niewykonalne to bez watpienia zapłacę fachowcowi
> za Open&Save w quarku.
Irytujesz mnie. Nie masz nawet tycieńkiego pojęcia o działaniu quarka, o
zasadach składu, o tym, co trzeba zrobić z plikiem _zanim_ się z niego
puści pdfa, żeby drukarnia sobie z nim poradziła a zachowujesz się
jakbyś wiedział wszystko. Przepraszam Cie najmocniej, ale jeśli ktoś tu
się zachowuje jak napuszony burak to na pewno nie my :/
Na początku chciałam się z Tobą skontaktować na priv i pomóc Ci poradzić
sobie samemu. Odechciało mi się :/
> Wiem, że to co pisze w oczach DTPowców jest może i śmieszne
Śmieszne nie. Niesmaczne. I nie Twój brak wiedzy tylko podejście do tematu.
EOT.
Lolalna Loja
> Dlatego pytam u
> źródła licząc na odpowiedź ścisłą typu: "kompozytowy pdf to zwykły pdf".
> I prawie taką otrzymałem ;)
No dobra :/
Pdf kompozytowy to pdf kolorowy. Jednak. Ponieważ. Drukarz drukuje z
czterech kolorów CMYK to W Twoim pdfie mogą znaleźć się tylko elementy
utrzymane w tej przestrzeni barwnej. Drukarz nie może tego zmienić.
> Z grubsza widzę że jeśli odrzuci się pierdoły o wielkościach marginesów i
> czcionkach które są absolutnie nieznaczące technicznie
Problem polega na tym, że to są elementy kluczowe, zwłaszcza przy
tekście technicznym. Chodzi o to, że tekst musi być czytelny - nie
przeszkadzać "optycznie" w przyswajaniu treści. Jeśli czcionka będzie za
mała, za duża, za cienka, będą za duże odstępy między wierszami, nie
będzie odstępów między akapitami, będą duże wcięcia w tekście
spowodowane brakiem łamania to informacje z takiej publikacji będzie się
przyswajało dużo gorzej niż z przemyślanego składu.
> tylko problem "jakiś zniekających elementów tekstu" co do których nie
> mam pewności gdzie i dlaczego mają znikać. Tu przyznaje, że moja wiedza
> jest poniżej dna, jednak coś mi mówi, że technologia od czasów
> wynalezienia druku chyba się nieco polepszyła i aż tak źle nie jest
> żebym miał dokumencie jedno a na wydruku co innego w sposób zasadniczy.
No niestety nie aż tak. My przeważnie wiemy co w tym, co mamy przed
oczami moze sprawiać problemy. Ty nie.
> Jeśli to wiedza z zakresu estetyki to nie chce jej.
Mówię o typografii (ważne jach cholera) oraz prawidłowym przygotowaniu
do druku (w tym również zasad na jakich druk się odbywa).
> Hmmm... a gdzie znajdę te podstawy chociaż troche spisane tak aby ocenić
> czy są faktycznie aż tak niezwykle zagmatwane.
Nie mam pojęcia. My to znamy z praktyki i często z książek, ale
bynajmniej nie tych typu "kurs maszynopisania w 24 godziny"...
InDesign Scripts
nie przejmuj sie ;)
jezeli to ma byc publikacja techniczna i cz/b i odpowiada Ci jej wyglad wg. Twojego projektu - to rob tak jak opisujesz ;)
zrob PDF'a i wydrukuj go na laserowce - jezeli wyjdzie wizualnie OK - to oddaj do naswietlarni :)
tylko pamietaj, zeby wszedzie byl jeden kolor - czarny z odcieniami :)
robin
--
Skrypty do AdobeFamily
www.adobescripts.pl
gg 3753393
tlen robinet
ICQ 20057375
Skype: AdobeScripts
Sebastian Bialy
>> To _nie jest_ problem ponieważ jak dobrze rozumiem jesli wykonam sobie
>> wydruk próbny to nie będzie zasadniczej różnicy w akurat tych
>> elementach. Więc argument że zobacze to dopiero z drukarni nie ma sensu.
> Rany...
Czy mam rozumieć że jesli na wydruku laserowym mam prostokąt to w
drukarni wyjdzie koło ? Tzn szukam uzasadnienia tego "rany ..." bo jeśli
dobrze widzę to by oznaczało że dostaje coś kompletnie innego. Jakich
różnić uzasadniających "rany..." mam się spodziewać?
>> _Chyba_ że wydruk z drukarni jest zasadniczo różny od wydruku na
>> przeciętnej laserówce.
> Jest. I nie tylko to jest problemem. Uwierz nam.
A co jeszcze?
> > Chodzi o standardowe metody analizy obrazu normalizujace histogram
>> obrazu? (tak mi wynika z google).
> Nie.
Więc w googlu nie ma konkretów. Przypuszczam wobec tego że chodzi o
akapity i przestrzenie w nich (cokolwiek to znaczy).
>> > utrzymanie
>> > registru itp.)
>>
>> Chodzi o zwykłe wyrównanie w pionie przez rozciągnięcie?
> Nie.
Może się źle wyraziłem, ale tu też jest 0 szans na odszukanie
czegokolwiek w googlu. Wygląda mi jednak na coś co ma związek z
odstępami bądź wysokością kolumny.
>> Jest to kwestia gustu.
> Nie.
Tu się nie zgodzę.
>> Tak przy okazji - dzielenie wyrazów nie jest trywialne ale wykonalne.
>> Na tyle jednak niewygodne technicznie, że nie wiem czy aby na pewno
>> warto je stosować. Nie jest w moim mniemaniu istotnym elementem.
>
>
> Wpisywanie <body> na początku pliku HTML jest trywialne i nie jest moim
> zdaniem istotnym elementem.
Mylisz wymóg standardu bez którego format jest nieczytelny z
_dodatkowym_ bajerem bez którego format jest dalej czytelny.
>> Dlaczego mają się źle drukować?
> Bo może być problem z ripowaniem czcionek, zwłaszcza przy starszych
> sterownikach.
Hmmm... mają w drukaniach dostęp do aktualizaji sterowników?
>> Tak z ciekawości co mnie może czekać: np. literka A nie będzie miała
>> poprzeczki w jakimś-tam-foncie?
> Będziesz miał krzaczki albo puste miejsca zamiast polskich znaków,
> posypią Ci się odległości między znakami, będzie bold tam gdzie go nie
> wpisywałeś... itd, itp...
Moment. Czy ja dobrze rozumiem, że to jest wina drukarni a nie moja?
Albo inaczej: daje im plik który zawiera określony wygląd a oni oddają
mi _inny_ wygląd i to jest moja wina? Hmm...
>> Bo nie uwierzę, że miszczowie od DTP dają plik i modlą się żeby coś
>> nie znikło.
> Uwierz.
No tak, byłem tego prawie pewien od początku. Średniowiecze
technologiczne ;)
>> W jaki sposób może się z nienacka coś pojawić?
> Np. coś jest ukryte, ale rip to widzi.
Jak może widzieć coś, czego ja na monitorze nie widzę? Jesli jest tak,
że pdf nie daje tego samego obrazu co maszyna drukarska to to jest
jakieś bagno mówiąc obrazowo i faktycznie zaczynam się poważnie
zastanawiać czy to ma sens. Nie przypuszczałem że napotkam na tak
debilny problem. Zawsze mi się wydawało że drukarnia robi metodą WYSIWYG
zakładając margines na błedy technologiczne. A tu się okazuje że
problemy rozwiązane 20 lat temu w informatyce nadal straszą w
drukarniach. Paranoja.
> Nie albo. Musi być CMYK. Jak zrobisz w RGB to Cię drukarnia wyśle na
> drzewo.
Nie ma problemu.
> Nie. Oni robią tak, jak mają w pliku. I nic sami z tym nie zrobią, nawet
> gdyby chcieli.
Jak to sami nic nie zrobią, przecież wydrukują mi zamiast Ą jakieś
krzaczki ... To albo się trzymają ściśle pliku albo go olewają.
>> Zwracam uwagę że dokument PDF będzie _perfekcyjny_ bo stworzony
>> automatycznie.
> ROTFL
Co rotfl? Sugerujesz że będę dodawał funkcję random do każdego
generowanego koloru? Będzie perfekcyjny logicznie i składniowo.
>> Tak na marginesie: jesli okaże się ze problemem będzie rozmiar to
>> zmiana rozmiaru to jakieś 20 sekund. Automatyka zadba o ponowny skład
>> w/g nowych norm.
> ROTFL 2.
Co rotfl2? Myślisz że ile zajmie mi zmiana jednego parametru i
puszczenie procesu xml->pdf na nowo?
> Ja tam widzę, że wręcz przeciwnie - wszyscy Ci mówią, że nie masz
> pojęcia a Ty idziesz w zaparte ;)
Bo nie mam pojęcia do czego się oficjalnie przyznaję. Problem tylko że
mówienie 3x Nie z twojej strony ani troche nie rozświetla problemu a
puste rotfl trudno traktować jako argument.
> Oczywiście wszystkie są w RGB i mają 72 dpi? ;)
Nie, musiś poćwiczyć telepatię. Wszystkie są w:
a) asymptote
b) graphwiz
c) svg
i występują w postaci źródeł.
>> Tex jest do tego bardzo niewygodny. Bez względu na problemy nie będzie
>> on moją platformą podstawową zapewne _nigdy_.
> Kup Adobe ;)
A w czym jest lepszy zakładając że mam do dyspozycji np. konsolę unixa w
której chciałbym poleceniem wykonać konwersję xml->pdf ?
>> Poprawnośc techniczną zapewni mi każda metoda generacji wyglądu w
>> sposób automatyczny w tym i mój xml->whatever->pdf.
> Ręce mnie byli opadli :)
Podczas klikania w adobe czy podczas wpisania "buildpdf" w konsoli unixa?
igoR szczurka
> Dlatego pytam u
> źródła licząc na odpowiedź ścisłą typu: "kompozytowy pdf to zwykły pdf".
> I prawie taką otrzymałem ;)
^^^^^^^^^^^^^^^^^^^^^^^^^
Widzisz to co chcesz widzieć?
"Zwykłego PDF" może być kilka rodzajów, z różnym przeznaczeniem. Większosć
z nich zazwyczaj nie nadaje się do profesjonalnego druku (nie że "nie
wypada, źle wygląda" tylko "nie działa, koniec, kropka"). Nie wszystkie
PDF przeznaczone do druku będą się poprawnie RIPować na _każdym_ z urządzeń.
Dlatego NIE MA ścisłej odpowiedzi.
Jest wiedza dlaczego i jak. Odpowiedź wynika z owej wiedzy i jest
ściśle zależna od sytuacji.
> Hmm... jak na razie po poście Marka Włodarza nie wystraszyłem się. Z
> grubsza widzę że jeśli odrzuci się pierdoły o wielkościach marginesów i
> czcionkach które są absolutnie nieznaczące technicznie to pozostaje
> tylko problem "jakiś zniekających elementów tekstu" co do których nie
> mam pewności gdzie i dlaczego mają znikać. Tu przyznaje, że moja wiedza
> jest poniżej dna, jednak coś mi mówi, że technologia od czasów
> wynalezienia druku chyba się nieco polepszyła i aż tak źle nie jest
> żebym miał dokumencie jedno a na wydruku co innego w sposób zasadniczy.
Owszem polepszyła się, wymaga jednak umiejętności zastosowania narzędzia
oraz (a może przede wszystkim?) wiedzy co jak i dlaczego w danym momencie
zastosować.
Bez względu na postęp technologii - nie gwarantuje ona z góry, że na
ekranie, laserówce i profesjonalnym RIPie otrzymasz identyczny wynik.
Wręcz przeciwnie - metody generowania Twojego materiału różnią się w tych
wypadkach diametralnie - więc BEZ "przygotowania" efekt może być
katastrofalny (a z całą pewnością NIE BĘDZIE poprawny)
Zresztą sam sobie odpowiedz:
"Mam program który poprawnie działa pod Windows. Czy mogę domowym spospobem
szybko go poprawić tak żeby działał również na MacOSX? W końcu to prawie
taki sam komputer i ma identyczny monitor. Czy będzie działać tak samo?"
:)
> Jeśli to wiedza z zakresu estetyki to nie chce jej. Bo będzie od razu 15
> opini na 10 grupowiczów. Jesli to wiedza techniczna (np dotyząca
> możliwości technicznych maszyn) to jestem bardzo zainteresowany bo tej
> właśnie szukam.
Do wiedzy o możliwościach maszyny to jeszcze nie doszliśmy. Utknęliśmy
ledwie na wstępie. Zresztą akurat brak tej 'końcowej' wiedzy nie zepsuje Ci
_kompletnie_ materiału (co najwyżej dramatycznie pogorszy estetykę bądź
jakość/czytelność)
> Hmmm... a gdzie znajdę te podstawy chociaż troche spisane tak aby ocenić
> czy są faktycznie aż tak niezwykle zagmatwane.
"Chciałbym napisać program. Kompletnie się na tym nie znam, ale mam już
gotowe ikonki do przycisków i wiem jak powinien wyglądać. To chyba powino
wystarczyć? Możesz mi podać jakieś usystematyzowane źródło wiedzy, które
pozwoli mi szybko skończyć dzieło? Tylko, wiesz, nie jakieś do nauki
programowania, bo nie potrzebuje tego. Najlepiej jakiś automat. Przecież
automaty się nie mylą. Załaduję graficzki i chcę żeby się zrobiło."
Co ty na to...?
Sądzisz że grupowicze są tak złośliwi, że skrzętnie ukrywają przed Tobą
przepastne źródło wiedzy? Nie.
Poza zasadami składu (a te Cię z niezrozumiałych dla mnie przyczyn nie
interesują?) IMO brak jest usystematyzowanych tego typu materiałów po
polsku. Zagranicznych nie znam (o ile są).
Minimum wiadomości oraz stosowne linki i literaturę znajdziesz w FAQ.
--
C
igoR szczurka |'_> FAQ grupy pl.comp.dtp
@ gmail com / | http://dtp.art.pl
| \\
---=============\___DD GG:5239818 / Skype:igor_sz
Sebastian Bialy
> Irytujesz mnie. Nie masz nawet tycieńkiego pojęcia o działaniu quarka, o
> zasadach składu, o tym, co trzeba zrobić z plikiem _zanim_ się z niego
> puści pdfa, żeby drukarnia sobie z nim poradziła a zachowujesz się
> jakbyś wiedział wszystko. Przepraszam Cie najmocniej, ale jeśli ktoś tu
> się zachowuje jak napuszony burak to na pewno nie my :/
Niezupełnie. Jak na razie poza bezustannym tłuczeniem mnie po głowie
hasłami typu "Nie, rotfl" nie dowiedziałem się co takiego magicznego
robi quark czego nie mogę zrobić automatycznie. Z chęcią się dowiem.
Poza postem Marka Włodarza w którym były konkrety i twoim we fragmencie
dotyczącym gubienia czcionek z ogonkami nic więcej się nie dowiedziałem
sensownego. Dalej uważam, że nie ma problemów nie do przeskoczenia.
Czekam aż mnie ktoś zastrzeli problemem którego nie rozwiąże. Wtedy
odejdę w pokorze.
> Na początku chciałam się z Tobą skontaktować na priv i pomóc Ci poradzić
> sobie samemu. Odechciało mi się :/
Bardzo dobrze, może ktoś skorzysta na grupie.
> Śmieszne nie. Niesmaczne. I nie Twój brak wiedzy tylko podejście do tematu.
Podejście do tematu jest proste: chce mieć zautomatyzowany proces
budujący mi plik pdf do drukarni z źródła (np xml). Jeśli poznam
wszelkie niezbędne elementy po drodze i natrafie na taki, którego nie
przeskoczę to projekt porzuce. Dlatego robie wywiad na grupie zadając
upierdliwe pytania. Taka moja rola w tej chwili.
Jeśli natomiast będzie światło w tunelu to podejme się próby.
Sebastian Bialy
> Pdf kompozytowy to pdf kolorowy. Jednak. Ponieważ. Drukarz drukuje z
> czterech kolorów CMYK to W Twoim pdfie mogą znaleźć się tylko elementy
> utrzymane w tej przestrzeni barwnej. Drukarz nie może tego zmienić.
I to jest konkret. Choć w żadnym razie nie przeszkadza mi on ponieważ
mogę zautomatyzować proces tworzenia docelowego pdfa własnie pod kątem
ograniczenia barw.
Inna sprawa, czy nie powinienem stosować jakiegoś specjalnego modelu
CMYK przeznaczonego do konkretnej maszyny? CMYK CMYKowi nie równy.
Pytanie: czy podczas upewniania się czy kolory mieszczą się w CMYK
wymagana jest wiedza o maszynie docelowej? A może jest tylko przydatna?
Lub zupełnie zbędna?
> Problem polega na tym, że to są elementy kluczowe, zwłaszcza przy
> tekście technicznym. Chodzi o to, że tekst musi być czytelny - nie
> przeszkadzać "optycznie" w przyswajaniu treści. Jeśli czcionka będzie za
> mała, za duża, za cienka, będą za duże odstępy między wierszami, nie
> będzie odstępów między akapitami, będą duże wcięcia w tekście
> spowodowane brakiem łamania to informacje z takiej publikacji będzie się
> przyswajało dużo gorzej niż z przemyślanego składu.
Mając na myśli pierdoły mam na mysli trywialnośc poprawy tego elementu w
procesie automatycznego budowania. To nie jest element techniczny
którego nie mogę osiągnąć. Wręcz jeden z najłatwiejszych. Oczywiście
nalezy przykładać uwagę do wyglądu ale bez względu na pomysł zawsze
można to łatwo przerobić xml->pdf aby generował inaczej. Czyli z punktu
widzenia trudności to jest nic.
> No niestety nie aż tak. My przeważnie wiemy co w tym, co mamy przed
> oczami moze sprawiać problemy. Ty nie.
Przypuszczam jednak że mozna to łatwo opisać. Coś w rodzaju "linie
mniejsze niż 0.1mm na maszynie xxx nie są drukowane","gradient taki a
taki zawsze wychodzi do d...".
W zasadzie pytanie jest proste: czy problemów nalezy spodziewac się w
tekście czy w grafice w większej częsci? Przypuszczam że w grafice.
igoR szczurka
> Podejście do tematu jest proste: chce mieć zautomatyzowany proces
> budujący mi plik pdf do drukarni z źródła (np xml). Jeśli poznam
> wszelkie niezbędne elementy po drodze i natrafie na taki, którego nie
> przeskoczę to projekt porzuce. Dlatego robie wywiad na grupie zadając
> upierdliwe pytania. Taka moja rola w tej chwili.
...i zabierasz się od dupy strony. :P
Może zacznij od bardziej prawidłowej - np. czystego PostScriptu - wszak to
w koncu język, więc siłą rzeczy programiście powinien być łatwiejszy do
przyswojenia. Jeśli uda Ci się generować prawidłowy postscript, z
prawidłowo osadzonymi fontami, dobrze zdefiniowanymi kolorami, przy
założeniu, że panujesz nad składem, marginesami, spadami; to konwersja
PS->PDF jest rzeczywiście do załatwienia prostym i ogólnie dostępnym
automatem, gdzie pilnując stosownych ustawień nie ma już szans na błąd.
Byćmoże przyda Ci się Ghostscript.
Sebastian Bialy
> "Zwykłego PDF" może być kilka rodzajów, z różnym przeznaczeniem. Większosć
> z nich zazwyczaj nie nadaje się do profesjonalnego druku (nie że "nie
> wypada, źle wygląda" tylko "nie działa, koniec, kropka").
Z ciekawości: dlaczego? Tzn co takiego jest złego w większości PDFów?
> Nie wszystkie
> PDF przeznaczone do druku będą się poprawnie RIPować na _każdym_ z urządzeń.
No właśnie. Ten RIP mi się nie podoba. Jesli dobrze kumam słuzy do
zapewnienia wektorowości kształtów aż do samego końca. To jest ok, tylko
nie bardzo rozumiem czemu kształt prostokąta na urządzeniu X ma się
ripować poprawnie a na Y nie. Jesli chodzi o fonty to jeszcze to
rozumiem, ale nie wiem czemu nie można mieć opcji fail-safe drukujacej
fonty jako krzywe w przypadku braku oryginału? Nawet w _lekko_ gorszej
jakości.
A co jesli będę chciał po chińsku napisać jedno zdanie? Mam je sobie w
obrazek przerobić?
> "Mam program który poprawnie działa pod Windows. Czy mogę domowym spospobem
> szybko go poprawić tak żeby działał również na MacOSX? W końcu to prawie
> taki sam komputer i ma identyczny monitor. Czy będzie działać tak samo?"
Tak. O ile zostanie napisany w przenośnym języku programowania. Co
_WŁAŚNIE_ próbuje zrobić walcząc xml->pdf w przypadku dtp.
> "Chciałbym napisać program. Kompletnie się na tym nie znam, ale mam już
> gotowe ikonki do przycisków i wiem jak powinien wyglądać. To chyba powino
> wystarczyć? Możesz mi podać jakieś usystematyzowane źródło wiedzy, które
> pozwoli mi szybko skończyć dzieło? Tylko, wiesz, nie jakieś do nauki
> programowania, bo nie potrzebuje tego. Najlepiej jakiś automat. Przecież
> automaty się nie mylą. Załaduję graficzki i chcę żeby się zrobiło."
>
> Co ty na to...?
Bzdura. Jest tak że mam gotowy system kontroli pozycji dowolego elementu
dokumentu. Wielkości czcionek, położenia akapitów, wszelkie duperele
związane z wyglądem który jest przecież właśnie celem. Czyli cały engine
jest. Brakuje duperelek typu dzielenie wyrazów, fikuśne "fi" i inne
dodatki kóre zapewne w ogóle okażą się niezauważone dla czytelnika.
Teraz mając GOTOWY poskładany dokument szukam możliwości wydruku w
drukarni. I wale głową w mur debilnych problemów typu "profesjonalny RIP
nie ma polskich czcionek i nie może sobie zwektoryzować tych co są". Mam
wrażenie że ktoś czegoś nie przemyślał.
> Sądzisz że grupowicze są tak złośliwi, że skrzętnie ukrywają przed Tobą
> przepastne źródło wiedzy? Nie.
Nie sądzę. Coś jednak udało się wydobyć.
> Poza zasadami składu (a te Cię z niezrozumiałych dla mnie przyczyn nie
> interesują?)
Zasady składu są elementem gustu i estetyki. A tej ubrać w ramy nie da
się a nawet gdyby to pewnie zrobił bym dużo wyjątków.
Sebastian Bialy
> ...i zabierasz się od dupy strony. :P
A miałbym zając się stwierdzeniem:
"Chce zrobić śliczny system budowania xml->pdf. Zrobiłem sobie na razie
tylko projekciki marginesów i kerningu i jest zarąbiście boskie. Co dalej?"
?
> Może zacznij od bardziej prawidłowej - np. czystego PostScriptu - wszak to
> w koncu język
Tak mówią tylko fanatycy ps ;) Taki z niego język jak z VisualBasica.
>, więc siłą rzeczy programiście powinien być łatwiejszy do
> przyswojenia. Jeśli uda Ci się generować prawidłowy postscript, z
> prawidłowo osadzonymi fontami, dobrze zdefiniowanymi kolorami, przy
> założeniu, że panujesz nad składem, marginesami, spadami; to konwersja
> PS->PDF jest rzeczywiście do załatwienia prostym i ogólnie dostępnym
> automatem, gdzie pilnując stosownych ustawień nie ma już szans na błąd.
No i dokładnie to potrafie uczynić w tej chwili. Tyle że nie ps a pdf.
Nie wiem czy to nie przeszkoda.
Z xml powstaje pdf który:
a) dobrze definiuje kolory (CMYK jest 0,0,0,100 dla tekstu i nie ma
prawa być inny)
b) prawidłowo osadzone fonty (przy czym dalej nie rozumiem po co je
osadzać zamiast zwektoryzować)
c) panuje nad składem i wszelkimi duperelami
Zakładając że dostanę takiego pdf'a to rozumiem, że drukarnia jest w
stanie z niego zrobić coś z duzym prawdopodobnieństwem ....
Sebastian Bialy
> tylko pamietaj, zeby wszedzie byl jeden kolor - czarny z odcieniami :)
Czarny z odcieniami :) ? A co to ?
InDesign Scripts
> zapewnienia wektorowości kształtów aż do samego końca. To jest ok, tylko
> nie bardzo rozumiem czemu kształt prostokąta na urządzeniu X ma się
> ripować poprawnie a na Y nie. Jesli chodzi o fonty to jeszcze to
> rozumiem, ale nie wiem czemu nie można mieć opcji fail-safe drukujacej
> fonty jako krzywe w przypadku braku oryginału? Nawet w _lekko_ gorszej
> jakości.
kiepsko uzywasz google ...
http://pl.wikipedia.org/wiki/Raster_Image_Processor
Sebastian Bialy
> kiepsko uzywasz google ...
> http://pl.wikipedia.org/wiki/Raster_Image_Processor
Dokładnie tą stronę znalazłem wczesniej.
Cytując:
"W DTP i poligrafii pod pojęciem ripa rozumie się dedykowane stanowisko
komputerowe ze specjalistycznym oprogramowaniem, podłączone do
naświetlarki lub do cyfrowej maszyny drukarskiej. Na ripie odbywa się
ostatni etap komputerowej części prac związanych z przygotowaniem do
druku. Ripuje się pliki postscriptowe, aby wysłać na urządzenie
wyjściowe gotowy obraz rastra (czyli siatki drukowanych punktów),
dokładnie w takiej postaci, w jakiej zostanie on potem wydrukowany."
Czyli do ostatniej możliwej chwili obraz jest wektorowy. Zamiana na
raster jest w ostatniej chwili przed wrzuceniem tego do fizycznego
urządzenia wyjściowego. Obawiam się więc, że rozumiem to dokładnie tak
jak działa. Dalej to nie tłumaczy debilnych problemów z czcionkami które
mogły by być ale nie są wektoryzowane.
A swoją drogą ...
zch2872
> [...] i cala reszta watku ;)
>
> nie przejmuj sie ;)
>
> jezeli to ma byc publikacja techniczna i cz/b i odpowiada Ci jej wyglad
> wg. Twojego projektu - to rob tak jak opisujesz ;)
>
> zrob PDF'a i wydrukuj go na laserowce - jezeli wyjdzie wizualnie OK - to
> oddaj do naswietlarni :)
> tylko pamietaj, zeby wszedzie byl jeden kolor - czarny z odcieniami :)
>
Już wiem skąd się bierze 3-godzinne ripowanie dokumentu albo ogólna jego
niechęć do ripowania.
Pełna beztroska. Świetlik do rana coś wymyśli żeby żaden ogonek nie
umknął. :-)
zch
InDesign Scripts
> raster jest w ostatniej chwili przed wrzuceniem tego do fizycznego
> urządzenia wyjściowego. Obawiam się więc, że rozumiem to dokładnie tak
> jak działa. Dalej to nie tłumaczy debilnych problemów z czcionkami które
> mogły by być ale nie są wektoryzowane.
bo caly dowcip polega na tym, ze jak masz FONTY to wysylane sa one RAZ a pozniej sa one tylko wstawiane przez urzadzenie we wlasciwych miejscach - dzieki temu od pewnego momentu - objetosc pliku spada w stosunku do pliku z zwektoryzowanymi tekstami
to tak jak z drukarkami iglowymi - wysylasz im kody znakow - a drukarka sama wie gdzie ma kropki postawic, zeby na papierze pojawil a sie literka
ale poza tekstem i obiektami wektorowymi - moga tez byc bitmapy - i one tez musza zostac zamienione na punkty - z uwzglednieniem rozdzielczosci wyjsciowej, liniatury, kolorow, itp
a ew. debilne problemy z fontami to moga byc wtedy, gdy np. zalozysz, ze RIP ma w sobie pewien font, ale ten jego font jest troche inny niz ten Twoj ;)
albo w przypadku, gdy fonty sa zle zrobione - np. stary problem z bodajze Switzerlandem z Corel'a - gdzie "ś" wychodzilo jako outline - bez wypelnienia ;)
InDesign Scripts
> niechęć do ripowania.
> Pełna beztroska. Świetlik do rana coś wymyśli żeby żaden ogonek nie
> umknął. :-)
bez przesady ;) ja grzecznie produkuje PDF'y w procesie destylacji PS'a ;)
a z tego co Sebastian pisze - to raczej wie jak zbudowac plik PDF ;)
tylko chyba niepotrzebnie "dyskutuje" ;)
Sebastian - zrob po prostu PDF'a - oddaj do naswietlarni/drukarni do weryfikacji/akceptacji - i juz :)
jak go zaakceptuja - ze sie nadaje do druku - to masz problem z glowy ;)
Sebastian Bialy
> bo caly dowcip polega na tym, ze jak masz FONTY to wysylane sa one RAZ a
> pozniej sa one tylko wstawiane przez urzadzenie we wlasciwych miejscach
> - dzieki temu od pewnego momentu - objetosc pliku spada w stosunku do
> pliku z zwektoryzowanymi tekstami
Przepraszam czy mamy może rok 2000 czy może 2007? Nie wiem czy ktoś
zauważył, że rozmiar pamięci rzędu 5GB kosztuje około 2zł w postaci
płyty DVD. Dalej chcesz w imię zmniejszania rozmiarów plików dostawać po
dupie w wyniku braku fontów? To jakaś paranoja. Czy pojęcie mniejszej
objętości pliku jest święte w dtp że nie można sobie wyobrazić innego
rozwizania?
> to tak jak z drukarkami iglowymi - wysylasz im kody znakow - a drukarka
> sama wie gdzie ma kropki postawic, zeby na papierze pojawil a sie literka
O! To dopiero przykład nowoczesnych technologii.
> ale poza tekstem i obiektami wektorowymi - moga tez byc bitmapy - i one
> tez musza zostac zamienione na punkty - z uwzglednieniem rozdzielczosci
> wyjsciowej, liniatury, kolorow, itp
I z rym radzi sobie bezproblemowo tandetny pecet za 1000zł wyświetlając
prawidłowo na ekranie i drukując na drukarce a nie radzi sobie maszyna
drukarska za kupę kasy ? Hmm.... Coś mi tu nie pasuje.
> a ew. debilne problemy z fontami to moga byc wtedy, gdy np. zalozysz, ze
> RIP ma w sobie pewien font, ale ten jego font jest troche inny niz ten
> Twoj ;)
Ależ ja mu font dostarczam. Osadzony w pliku. Zewnątrzny. Whatever. Czy
łaskawie wtedy go zauważy?
Wybacz ale to co piszesz jest trudne do uwierzenia. Przecież technologia
komputerowa nie zatrzymała się w czasach 64MB RAM. Dzisiaj dyskusja że
plik jest za duzy nie ma sensu. Są pojemne nośniki, jest internet.
Rozmiary rzedu setek GB nikogo nie dziwią.
Czy aby na pewno problemy z fontami i innymi duperelami samego procesu
RIP nie wynikają po część z używania przeraźliwie starych technologii w
większości drukarni? Może warto znaleźć taką gdzie zainwestowano w
wymianę oprogramowania na takie widzące sensowne rozmiary plików?
Sebastian Bialy
> jak go zaakceptuja - ze sie nadaje do druku - to masz problem z glowy ;)
Postraszono mnie że:
a) znikają literki
b) pojawiają się literki
c) pojawiają się krzaczki
d) pojawiają się inne przypadkowe elementy które rpi widzi
e) znikają inne przypadkowe elementy których rip nie widzi
f) ...
To nie napawa optymizmem. Czapka z głów jeśli przeciętny dtpowiec spędza
upoijne chwile szukając potencjalnych problemów i gryzie paznokcie po
oddaniu pracy do drukarni czy aby na pewno Ą wyjdzie. A podobno PDF to
skrót od _Portable_ Document Format...
Wojtek Gryniewski
> To nie napawa optymizmem. Czapka z głów jeśli przeciętny dtpowiec spędza
> upoijne chwile szukając potencjalnych problemów i gryzie paznokcie po
> oddaniu pracy do drukarni czy aby na pewno Ą wyjdzie.
Przeciętny DTPowiec wie co zrobić, żeby ich nie szukać.
Masz klapki na oczach. Rób automatem. Nie zapomnij się tylko pochwalić jak
wyszło. Chętnie poczytamy.
--
"Dla podkreślenia wagi moich słów,
Siłacz palnie pięścią w stół."
J. Christa
Tomasz Kuc
> Ponieważ nie bywam na tej grupie regularnie to pytanie: Czy mam
> przyjemnośc z jakimś lokalnym debilem, czy też to jakiś odosobniony
> przypadek neostradowy ?
Tak, to lokalny troll, nie przejmuj się
Tomek
Lolalna Loja
> Bzdura. Jest tak że mam gotowy system kontroli pozycji dowolego elementu
> dokumentu. Wielkości czcionek, położenia akapitów, wszelkie duperele
> związane z wyglądem który jest przecież właśnie celem. Czyli cały engine
> jest.
Zrozum wreszcie, że to co próbujesz zrobić ma z informatyką, xmlem,
engine i innym niewiadomoczym tyle wspólnego co ja z chińskim baletem :///
> Zasady składu są elementem gustu i estetyki.
Zasady składu jak sama nazwa są powszechnie obowiązującymi w DTP
zasadami. To co jest zasadą nie może być elementem gustu.
InDesign Scripts
Ty jednak naprawde jestes zarozumialy i nie potrafisz sluchac ...
nie chodzi o PRZYNIESIENIE danych - te moga zajmowac i 10 plyt DVD - chodzi o czas potrzebny na PRZETWORZENIE danych
Tomasz Kuc
1. Ustal z drukarnią format netto (po obcięciu). Niestety
często okazuje się, że w ustach drukarza "a4" to np. 205 x 287 mm
2. Jeśli Ci to nie sprawi problemu, wygeneruj PDFa z liczbą stron
podzielną przez 16.
3. Trzymaj się na razie jednego koloru, tj. czarnego.
Dopilnuj, aby był definiowany w modelu CMYK (czyli 0%C, 0%M, 0%Y, 100%K)
W pełnym CMYKu musiałbyś kontrolować inne parametry,
jak total ink limit, GCR/UCR, chyba nie ma sensu.
4. Dogadaj się z drukarnią/naświetlarnią na impozycję Twojego pliku.
Drukarnia pewnie współpracuje z jakąś naświetlarnią, do niej dostarczysz
plik PDF. Umów się na wydruk próbny (dawniej ozalid), przed drukiem
obejrzysz sobie na papierze, czy to co popełniłeś warto drukować
w większym nakładzie ;)
O innych problemach już się naczytałeś ;)
Powodzenia. I daj znać na grupie jaki jest wynik.
Ew. wystaw PDFa do obejrzenia przed drukiem, o ile nie jest
to jakiś poufny plik lub masz obawy, że "rozejdzie się" po sieci.
Pozdrawiam
Tomek
Lolalna Loja
> Czy mam rozumieć że jesli na wydruku laserowym mam prostokąt to w
> drukarni wyjdzie koło ?
Masz rozumiec, że jeśli na drukarce laserowej wyszedł Ci śliczny lasek
na zdjęciu i okrąglutkie pliterki to w drukarni może wyjść coś innego,
jeśli plik jest nieprawidłowo przygotowany.
> Tzn szukam uzasadnienia tego "rany ..." bo jeśli
> dobrze widzę to by oznaczało że dostaje coś kompletnie innego. Jakich
> różnić uzasadniających "rany..." mam się spodziewać?
Uzasadnienie tego "rany" jest takie, że zamiast próbować uprzejmie
zdobyć wiedzę i po prostu zapytać "mam to i to co zrobić, żeby było
dobrze" piszesz "ja i tak wiem, ze DTP to jedna wielka ściema, więc mi
nie mówcie a w ogóle to ja i tak wiem swoje"
>> Jest. I nie tylko to jest problemem. Uwierz nam.
>
> A co jeszcze?
Problem polega na tym, że problemów może być cała masa i nikt Ci ich
tutaj nie wyliczy. Bo trzeba by najpierw zobaczyć nawet nie pdfa tylko
to, z czego ten pdf ma być zrobiony. I to dokładnie a nie zerknąć.
> Więc w googlu nie ma konkretów. Przypuszczam wobec tego że chodzi o
> akapity i przestrzenie w nich (cokolwiek to znaczy).
Trafiony.
>> Wpisywanie <body> na początku pliku HTML jest trywialne i nie jest
>> moim zdaniem istotnym elementem.
>
> Mylisz wymóg standardu bez którego format jest nieczytelny z
> _dodatkowym_ bajerem bez którego format jest dalej czytelny.
Dla nas to jest wymóg standardu. Dobra. Nie <body> tylko <title>. Bez
tego tez działa.
> Hmmm... mają w drukaniach dostęp do aktualizaji sterowników?
Czasem mają a czasem nie.
> Moment. Czy ja dobrze rozumiem, że to jest wina drukarni a nie moja?
Źle rozumiesz. Generujesz plik, z którym drukarnia ma kłopoty przez to,
że nie wiesz jak to zrobić i wsadzasz rzeczy, które są hm... ryzykowne.
Każdy dtpowiec o tych rzeczach wie i ich unika. Nie wymienię Ci. Dużo
tego i od wielu rzeczy zależy.
> Albo inaczej: daje im plik który zawiera określony wygląd a oni oddają
> mi _inny_ wygląd i to jest moja wina? Hmm...
Tak. To jest Twoja wina, bo skopałeś przygotowanie do druku. WYSYWIG w
DTP nie istnieje.
> No tak, byłem tego prawie pewien od początku. Średniowiecze
> technologiczne ;)
Raczej brak niezawodności "maszyn liczących", w którą Ty święcie wierzysz.
> Jak może widzieć coś, czego ja na monitorze nie widzę?
Bo na monitorze to wiele można zobaczyć (lub nie). W druku masz to, co
jest zapisane do pliku. Na przykład nadrukowania.
> A tu się okazuje że
> problemy rozwiązane 20 lat temu w informatyce nadal straszą w
> drukarniach.
Masz rację - nie powinieneś zmieniać zawodu.
>> Nie. Oni robią tak, jak mają w pliku. I nic sami z tym nie zrobią,
>> nawet gdyby chcieli.
>
> Jak to sami nic nie zrobią, przecież wydrukują mi zamiast Ą jakieś
> krzaczki ... To albo się trzymają ściśle pliku albo go olewają.
To nie oni wydrukują, tylko maszyna drukarska a właściwie wcześniej
naświetlarka. Są fonty, które nie współpracują z ripem lub nie robią
tego jak należy, bo są nazwijmy to "starego typu" (część systemowych
spod win na przykład) i żaden normalny dtpowiec w składzie ich nie użyje
>>> Zwracam uwagę że dokument PDF będzie _perfekcyjny_ bo stworzony
>>> automatycznie.
>> ROTFL
>
> Co rotfl?
Sugeruję, że za bardo wierzysz w automatyzację procesów i niezawodność
generatorów tej automatyzacji. Gdyby tak było to nie byłoby tyle roboty
dla DTPowców.
>>> Tak na marginesie: jesli okaże się ze problemem będzie rozmiar to
>>> zmiana rozmiaru to jakieś 20 sekund. Automatyka zadba o ponowny skład
>>> w/g nowych norm.
>> ROTFL 2.
>
> Co rotfl2?
Automatyka.
>> Oczywiście wszystkie są w RGB i mają 72 dpi? ;)
>
> Nie, musiś poćwiczyć telepatię. Wszystkie są w:
>
> a) asymptote
> b) graphwiz
> c) svg
>
> i występują w postaci źródeł.
Przełóż mi to na dtp bo ja informatykiem nie jestem - jak tak wyjedziesz
drukarzowi to Cię spuści ze schodów.
>>> Tex jest do tego bardzo niewygodny. Bez względu na problemy nie
>>> będzie on moją platformą podstawową zapewne _nigdy_.
>
>> Kup Adobe ;)
>
> A w czym jest lepszy zakładając że mam do dyspozycji np. konsolę unixa w
> której chciałbym poleceniem wykonać konwersję xml->pdf ?
Adobe służy do składu między innymi właśnie. Niestety pod Unixem nie
działa. Masz pecha.
>>> Poprawnośc techniczną zapewni mi każda metoda generacji wyglądu w
>>> sposób automatyczny w tym i mój xml->whatever->pdf.
>> Ręce mnie byli opadli :)
>
> Podczas klikania w adobe czy podczas wpisania "buildpdf" w konsoli unixa?
Cały czas nie pojmujesz, że błędy nie wystąpią na etapie generowania
pdfa tylko pojawią się wcześniej.
Tomasz Szafranowski
chce zrobić pdfa drukowalnego, wszyscy pozostali zaś mówią o pdfie, którego
treść jest złożona zgodnie z zasadami sztuki dtpowsko-drukarskiej. To jakby
nie do końca to samo.
I szczerze mówiąc, nie widzę najmniejszego powodu, aby Sebastianowi miało
się to nie udać. W końcu TeX to też w pewnym sensie automat, a jakości pdfów
generowanych z TeXa nikt nie podważa - zarówno pod względem drukowalności,
jak i jakości składu. Ma rację Robin pisząc, że prawdziwa weryfikacja
dokumentu nastąpi w drukarni. I z tego, co wcześniej napisał Sebastian, nie
wynika nic co miałoby mu przeszkodzić jego w druku.
Czy jego dokument będzie dobry (w sensie - zgodny z zasadami sztuki)? To już
chyba jakby inny problem. Ze szczątkowego opisu tego co ten automat robi,
skłonny jestem domniemywać, że treść jego dokumentu bliższa jest "wykazowi
kodów serwisowych do pilotów" niż "Władcy pierścieni" (ale może się mylę).
Można taki "wykaz" (40 stronicowa tabela, 2 kolumny) zrobić po dtpowsku,
nowocześnie, dynamicznie, interesująco? Pewnie można....
Do Sebastiana: możemy zobaczyć chociaz jedną stronę tego pdfa?
--
Tomasz Szafranowski
"Impozycjoner" - do impozycji druków jednokartkowych
www.zpfilip.pl
Wojtek Gryniewski
> Mam wrażenie, że dyskusja jest jakby o dwóch różnych rzeczach: Sebastian
> chce zrobić pdfa drukowalnego, wszyscy pozostali zaś mówią o pdfie, którego
> treść jest złożona zgodnie z zasadami sztuki dtpowsko-drukarskiej. To jakby
> nie do końca to samo.
Zaraz zaraz... Sebastian w pierwszym poście napisał o złożeniu *KSIĄŻKI*, a
to już chyba nie jest tylko zrobienie drukowalnego PDFa.
Tomasz Szafranowski
news:1xd99bvj8mt5p$.ljrlchg2s5gu$.dlg@40tude.net...
> Dnia Thu, 29 Mar 2007 10:01:55 +0200, Tomasz Szafranowski napisał(a):
> Zaraz zaraz... Sebastian w pierwszym poście napisał o złożeniu *KSIĄŻKI*,
> a
> to już chyba nie jest tylko zrobienie drukowalnego PDFa.
Ale też napisał:
"Tak, ponieważ ta książka jest bardzo rózna od typowych książek:
konkretnie posiada bardzo dużo odsyłaczy nad którymi muszę zapanować w
sposób którego nie posiadają biurowe edytory tekstu. Ponadto częśc
elementów ksiązki jest generowanych. Nie sposób ich zapisać "raz a
dobrze w wordzie". To skomplikowana sprawa. Mówiąc skrótowo: nie jest to
książka pisana przez humanistę."
Dlatego "wniosek" o udostępnienie choćby jednej, typowej strony.
Tomasz Nowicki
> Dokładnie z tego powodu nie zamierzam się tym chwalić.
Hmm - to po co ci właściwie ta książka, skoro nie zamierzasz nikomu jej
pokazywać?
> Hmm a co dodatkowo ? Zaznaczam, że wygląda samego dokumentu przygotowuję
> samodzielnie. Czy poza dodtkowym podziałem wyrazów w końcowym wydruku
> można znaleźć coś jeszcze ? Czy chodzi np. o przygotowanie palety tak
> aby wyglądała sensownie?
Szczerze - nie bardzo rozumiem, co miałeś na myśli pisząc to zdanie.
Jakie jeszcze rzeczy mają znaczenie w składzie tekstu? Setki, jeśli nie
tysiące! Word wiele zrobi automatycznie, ale znacznie mniej, niż
potrzeba, by mieć przyzwoity skład. Wycinkowo - polecem zapoznanie się z
książką "Typografia typowej książki" Roberta Chwałowskiego - pozycja
niegruba, a treściwa.
> Tak, ponieważ ta książka jest bardzo rózna od typowych książek:
> konkretnie posiada bardzo dużo odsyłaczy nad którymi muszę zapanować w
> sposób którego nie posiadają biurowe edytory tekstu. Ponadto częśc
> elementów ksiązki jest generowanych. Nie sposób ich zapisać "raz a
> dobrze w wordzie". To skomplikowana sprawa. Mówiąc skrótowo: nie jest to
> książka pisana przez humanistę.
Jest taki język programowania, TeX, służący wyłącznie do generowania
składu książek, głównie technicznych. Ale jego "rozpoznanie bojem" to
najmniej kilka miesięcy zabawy...
> Toretycznie tak. Praktycznie pierwszy wydruk dopuszczam w odcieniach
> szarości. Kolor zostawiam na później, choć jeśli okaże się, że nie
LOL - chcesz, żeby ci drukarnia zrobiła "pierwszy wydruk w odcieniach
szarości"??? Masz _jakiekolwiek_ pojęcie o produkcji wydawniczej? Możesz
zrobić jedno wydanie w szarościach, następne w kolorze - ale proces
produkcji leci od nowa (może poza etapem prepress).
> Nie widze różnicy pomiędzy składaniem jednej strony A4 a 500 stron
> ksiązki - mam na myśli technikę. Ilość nie ma znaczenia tym bardziej że
> mechanizmy składania w 99% dostarczam samodzielnie i jest on skalowalny
> do dowlonych rozmiarów.
No cóż, skoro jesteś taki pewny siebie... Mógłbym napisać, że nie widzę
różnicy między napisaniem procedurki wyświetlającej napis "hello world",
a napisaniem Photoshopa, ale nie chcę się znęcać...
> Word jest _wymczasowy_. Nazwijmy go po prostu edytorem tekstu. Skład
> wykonać mogę (i docelowo wykonam) w xml->pdf.
A masz jakieś pojęcie o zasadach składu tekstu? Na czym się oprzesz?
> Rozumiem, że bez zainwestowania pieniędzy moje literki w książce będą
> wyglądały jakoś zasadniczo inaczej? Jakie konkretnie problemy będę mógł
> zaobserwować w wynikowym dokumencie?
Błędy składu i typografii - co najmniej.
> O to świetnie, bo widzisz jesli w kodzie programu są komentarze, to
> widocznie programista musiał coś niezrozumiałego skomentować. Ja
Nie każda analogia dopuszcza szczegółową analizę :)
> ludziom z mojego otoczenia również) przenoszenie wyrazów przeszkadza niż
> pomaga.
Niewykluczone. Znam takich, którzy za nic nie założą skarpetek, bo im to
przeszkadza. Ale do garnituru - jednak czasem zakładają. Wiesz dlaczego?
> a) mogę uzyskać dowolny wygląd końcowego dokumentu pdf (wszelkie
> elementy graficzne zostają wygenerowane w transformacji xml->pdf),
Sęk w tym, że tak naprawdę NIE WIESZ co powinieneś uzyskać - masz o tym
jedynie mętne pojęcie.
> to co nam jeszcze pozostaje ze "składu tekstu" ? To jest całkiem serio
> pytanie.
A ja serio odsyłam do literatury przedmiotu - zaoszczędzi to zbędnego
klepania w klawisze.
> Ah. Czyli po prostu pdf. Chyba że jesli dobrze doczytuje z internetu:
> niekiedy należy go jednak rozseparować na CMY(K)?
Zrobi to drukarnia. Warto jednak ilustracje dać od razu w przestrzeni cmyk.
> Gdzie mogę znaleźć informacje o tych "problemach"? Własnie to interesuje
> mnie najbardziej.
M. in. w archiwum tej grupy. Niestety, wymaga to wysiłku i czasu, nic na
tacy.
> "Fachowcy" robią strasznie skomplikowaną rzecz: dostają _pięknie_
> wyglądający dokument w wordzie z wzorowymi stylami. I generują pdf.
> Jesli robią coś pomiędzy to chciałbym wiedziec co takiego. Zakładam dla
> bezpieczeństwa, że mamy druk w odcieniach szarości.
Zapytaj ich, za co dokładnie im płacisz i już - masz do tego prawo :)
> poczytać bez zbędnego nadęcia ze strony "mistszuf dtp". Choćby tylko po
> to aby zarzucić ten pomysł. Bo przeciez nie zamierzam tego robic, jesli
> to niewykonalne.
Niewykonalne to może nie - ale JAK wykonalne - jeśli kompletnie nie
zależy ci na jakości - zrób to sam, w końcu zwykle przyjemnie jest
zdobywać nowe doświadczenia :)
> O ile okaże się, że to niewykonalne to bez watpienia zapłacę fachowcowi
> za Open&Save w quarku. Jednak zanim to zrobie chciałbym wiedzieć co
Za open and save nie ma co płacić - do takiego fachowca bym nie poszedł.
Ale zrobić książkę ze składu w Wordzie to nie jest opane and save.
> takiego niezykle trudnego pomiędzy się dzieje. I czy aby na pewno wymaga
> to quarka/whatever.
Gdyby nie, to fachowcy od quarka dawno poumieraliby z głodu.
> Wiem, że to co pisze w oczach DTPowców jest może i śmieszne, jednak
> pozwole sobie być upartym w dążeniu do wiedzy. Może się okazać, że nie
> taka ona straszna.
Oczywiście - tyle, że czasem jej zdobycie bywa okupione kosztami,
zwłaszcza gdy człowiek bierze się za to, excuse my French, od d... strony
T.
Marek Włodarz
Sebastian Bialy napisał(a):
> Marek Włodarz wrote:
> > Mam dziwne wrażenie, że drzewa przesłoniły ci las.
>
> Bardzo możliwe. Tylko że u mnie te drzewa to dość istotny składnik lasu ...
>
> > Kompozycja (w szerokim znaczeniu) - zarówno najogólniejsza, czyli
> > właściwe zaprojektowanie marginesów, dobranie właściwych czcionek dla
> > poszczególnych elementów tekstu, odpowiednich proporcji itp., jak
> > i szczegółowa. Tego się trzeba po prostu nauczyć i raczej nie da się
> > tego wyłożyć w kwadrans. Ani w tydzień. Może w rok.
>
> To _nie jest_ problem ponieważ jak dobrze rozumiem jesli wykonam sobie
> wydruk próbny to nie będzie zasadniczej różnicy w akurat tych
> elementach.
> Więc argument że zobacze to dopiero z drukarni nie ma sensu.
> _Chyba_ że wydruk z drukarni jest zasadniczo różny od wydruku na
> przeciętnej laserówce. Wtedy rzeczywiście to jest problem. Jednak
> trzymając w ręku przygotowany wydruk i ksiązkę nie dostrzegam
> specjalnych różnic w wyglądzie dowolnych elementów.
Więc jednak miałem rację - nie widzisz lasu (a co gorsza chyba nie
chcesz go zobaczyć).
Otóż ja nie napisałem prawie nic o tym, do czego się odnosisz.
Przez analogię - ja mówię o tym, czy obraz (olejny) jest dobry, czy
też zły, a ty o technice przędzenia włókien na płótno, na którym go
namalowano...
> Pozwole sobie więc powiedziec, że ewentualny problem to kwestia gustu i
> jak najbardziej do przeskoczenia z mojej strony.
OK, skoro tak uważasz - z gustem faktycznie się nie dyskutuje. Co
najwyżej głosuje portfelem.
> > Właściwe prowadzenie tekstu (kerning
>
> Chodzi o słynne "fi" w Tex ?
Nie mam bladego pojęcia, jak to się nazywa w TeX (tak się to pisze),
ale to jest to coś, czego na pewno nie ujrzyszy w tym poście (o ile
używasz, jak większość, czcionki stałopozycyjnej do wyświetlania
newsów).
> >, wyrównanie świateł,
>
> Chodzi o standardowe metody analizy obrazu normalizujace histogram
> obrazu? (tak mi wynika z google).
Brzmi mądrze, być może naukowo tak się to nazywa. W praktyce chodzi
o to, aby blok tekstu - a ogólniej cała kolumna - była możliwie
jednolicie "szara". Ja i inni, którzy robią to praktycznie, nazywają
to wyrównaniem świateł. I skądinąd wiem, że nie jest to trywialne
zadanie.
> > utrzymanie
> > registru itp.)
>
> Chodzi o zwykłe wyrównanie w pionie przez rozciągnięcie?
NIE. Pogooglaj dalej.
> > - programy do składu potrafią to zrobić, edytory tekstu
> > raczej nie, a co do opisywanego przez ciebie narzędzia do tworzenia
> > PDF z XML - niemal _na pewno_ nie. No, chyba że to jest jakiś godny
> > następca TeX-a. Ale w to wątpię.
>
> Może wątpić, a ja tylko delikatnie wspomnę, że o ile mogę sobie bez
> kłopotu zrobić xml->pdf to równie bez kłopotu mogę sobie zrobić
> xml->tex. Xml to powiedzmy taki mój sposób prywatny trzymania treści i
> logicznego jej podziału. Jeśli kerning jest kluczowy to nie ma problemu
> zrobie xml->tex->pdf i będzie. Pozostałe bajery mogę zrobić również
> automatycznie bądź półautomatycznie.
I to pewnie będzie najlepszy sposób, jakkolwiek punkt pierwszy mojego
poprzedniego posta pozostaje nadal do zrobienia.
Oczywiście możliwym jest, że rzucony przez ciebie od niechcenia szkic
będzie doskonały. Tyle że w to również wątpię. Z jakiegoś powodu tego
zawodu ludzie uczą się po 5 i więcej lat.
> > Przestrzeganie ogólnie ustalonych reguł dla składu książek.
>
> Hmmm. Są gdzieś spisane? Mam nadzieję, że nie znajdę tam haseł typu
> "spis treści piszemy fontem xxx, w odstępie 1.654mm, z kropkami
> wiodącymi ... etc" bo to akurat też kwestia gustu i estetyki którą można
> samodzielnie wypracować dla danej ksiązki.
Takich akurat rzeczy nie znajdziesz, chociażby dlatego, że nikt w tej
branży nie używa milimetrów jako jednostki miary... :>
Są reguły, ale ogólne. Jak dzielić wyrazy. Jakich kresek używać w
zależności od kontekstu. Jak dobierać proporcje stopnia pisma,
interlinii do rozmiarów łamu i kolumny. Jak wyróżniać tytuły czy
wypunktowania lub przypisy.
Istnieje to w postaci polskiej normy, a raczej bardzo licznych norm:
http://typografia.info/index.php?option=com_content&task=view&id=17&Itemid=6
W bardziej strawnej wersji - proponuję, abyś zaczął od lektury książki
Roberta Chwałowskiego "Typografia typowej książki" - jego wskazania są
uniwersalne i choć z niektórymi można polemizować, generalnie należy
ich przestrzegać.
> > Na temat niedzielenia wyrazów i argumentu, że dzielenie przeszkadza -
> > jest to dla mnie absolutna nowość, jako że wszystkie chyba znane
> > badania na ten temat głoszą coś dokładnie odwrotnego. Szczególnie
> > dotyczy to języka polskiego, w którym występuje stosunkowo dużo
> > "długich" wyrazów.
>
> Jest to kwestia gustu. Tak przy okazji - dzielenie wyrazów nie jest
> trywialne ale wykonalne. Na tyle jednak niewygodne technicznie, że nie
> wiem czy aby na pewno warto je stosować. Nie jest w moim mniemaniu
> istotnym elementem.
Jest bardzo istotnym elementem, jeśli jego brak spowoduje (a
spowoduje) gorszy wygląd i obniżenie czytelności tekstu. Nie
wspominając o tym, że powinno się je stosować, jeśli tekst jest
justowany - a niejustowany w języku polskim wygląda źle, głównie
dlatego, że nie jesteśmy do niego przyzwyczajeni.
> > Mogę się założyć o cokolwiek, że - przy takich założeniach i
> > nastawieniu - wytworzony przez ciebie skład będzie być może dawał się
> > czytać, ale na pewno nie będzie estetyczny...
>
> Tutaj znowu pytanie czy estetyka jest podstawowym założeniem i czy
> akurat dzielenie wyrazów jest tak kluczowe dla estetyki.
Patrz wyżej. Jest. I estetyka jest - po treści - najważniejszym
atrybutem gotowej książki. Oczywiście, nawet najpiękniejszy skład nie
uratuje książki nudnej czy też głupiej - ale zły skład może zabić
książkę ciekawą lub mądrą. Jasne?
> > może wszystko - od źle drukujących się znaków, przez nieoczekiwane
>
> Dlaczego mają się źle drukować? Tak z ciekawości co mnie może czekać:
> np. literka A nie będzie miała poprzeczki w jakimś-tam-foncie? Hmmm...
Nie, np. okaże się, że w całym tekście "znikła" litera ł. Albo ą. Albo
wszystkie diakrytyki. Albo np. greckie "chi" zostało zastąpione jakąś
dziwną kropą (a inne greckie są OK). Albo... Te i inne takie efekty są
bezpośrednim skutkiem użytych fontów (czytaj - błędów tych fontów),
ale bywa, że ten sam font użyty w różnych programach drukuje się raz
dobrze, a raz źle - po prostu nie każdy program umie "sięgnąć" do
wszystkich cech fontu.
Otóż stawiam mercedesa przeciwko orzechom, że twój program sięgnąć nie
będzie umiał, chyba że od 5 lat zajmujesz się projektowaniem fontów i
programów drukujących (a i wtedy nie dałbym Ci 100% szan, najwyżej
99...)
> czy to aby nie jest problem drukarni ocenić to wstępnie? Bo nie uwierzę,
> że miszczowie od DTP dają plik i modlą się żeby coś nie znikło.
Napisałeś, że w twojej książce będą różne "dziwne znaki" - skąd
drukarnia ma wiedzieć, czy to, co im wychodzi, jest tym, co ma wyjść?
Oczywiście, można (i trzeba) zrobić próbę i to Ty będziesz musiał
sprawdzić. Ale jeśli wydarzy się jedna wymienionych przeze mnie
rzeczy, spędzisz następnych kilka dni na szukaniu przyczyny, a
kolejnych kilka - na usuwaniu błędu. Been there, seen that.
> > podstawienia
>
> co to ?
Znaki, które drukują się zamiast innych. Np. z innej strony kodowej.
Hiszpańska "enia" zamiast ń czy funt sterling zamiast Ł. Zdarza się
coraz rzadziej, ale nie można wykluczyć.
> >, znikanie pewnych elementów lub pojawianie się
> > niechcianych
>
> W jaki sposób może się z nienacka coś pojawić? Czy masz na myśli np.
> smugi na gradiendach? To jeszcze jestem w stanie zrozumieć, ale jeśli
> powiesz mi że pojawiają się przypadkowe linie, punkty itd na pustej
> przestrzeni to będę co najmniej zdziwiony.
Możesz być zdziwiony - to też jest możliwe. Miałem kiedyś serię
rysunków generowanych z jakiegoś automatu właśnie - zamieniał odczyty
jakiejś aparatury pomiarowe na wykresy, od razu w postscripcie. Na
pozór wyglądały świetnie, na drukarce też nie było problemów - dopiero
w naświetlarni okazało się, że otoczone były kilkunastoma liniami
o grubości 1:1000 cala. Drukarka tego oczywiście nie odwzorowała...
a próba edycji tych EPSów w jakimkolwiek programie graficznycm kończyła
się nieodwołalnie powieszeniem systemu, bo "tfurca" tego dzieła
wykorzystywał rekurencję do generowania rastrów wypełniających
poszczególne elementy :>
Ale nie chodzi mi o tak "egzotyczne" przyczyny. Mam na myśli np. coś
takiego, że przykryjesz część rysunku białym prostokątem, aby na nim
umieścić opis (legendę, whatever) i na ekranie oraz drukarce będzie
OK, a w naświetlarni "wylezą" elementy przesłonięte. Jak najbardziej
możliwe. Inny wariant to biały napis na ciemnym/kolorowym tle, który
automagicznie "zniknie" w druku. Owszem, to jest błąd i wiadomo, jak
go uniknąć. Tzn. ja (a także owi "pośrednicy", których chcesz uniknąć)
o nim wiem. Ty się właśnie dowiedziałeś.
Tyle, że takich potencjalnych min są tysiące. Naprawdę nie czuję się
na siłach wypisać ci wszystkiego, co trzeba sprawdzać. Ja to robię po
prostu odruchowo i prawie "nieświadomie" - a i tak od czasu do czasu
zdarzają mi się wpadki. Rzecz w tym, aby je wyłapać _przed_ wydrukowaniem
nakładu..
> >, aż po rozseparowanie czarnego tekstu na wszystkie
> > składowe...
>
> Nawet jesli tekst będzie czarny np. R=0,G=0,B=0 albo C=0,M=0,Y=0,K=100%
Hm... O ile to drugie jest w porządku, to tego pierwszego raczej nie
radziłbym umieszczać w wynikowym pliku. Widzisz, to kolejna rzecz, o
której nie wiesz, choć powinieneś. Te dwa zapisy w żadnym stopniu NIE
są równoważne.
> ? To już mi pachnie błędem drukarni.
Nie, to będzie twój błąd. Drukarnia może go co najwyżej wychwycić
i wstrzymać druk, domagając się poprawy. Nic więcej.
> Zwracam uwagę że dokument PDF
> będzie _perfekcyjny_ bo stworzony automatycznie. Nie ma tam błędów typu
> "prawie czarny tekst".
Rozbawiłeś mnie... A co, myślisz, że inni tworzą PDF ręcznie, czy co?
Piszą w hexach?
Dowiedz się może, bo najwyraźniej tego nie rozumiesz - PDF to tylko
"kontener". Co do niego włożysz, to dostaniesz. Przyjmie z
dobrodziejstwem inwentarza niemal każdą bzdurę, którą ktoś zechce do
niego wstawić, bo jest to format _bardzo_ elastyczny. Dla wyjaśnienia
- równie elastyczny jak Postscript (którego jest dalekim potomkiem).
"Automatyczność" tworzenia nie bardzo ma cokolwiek do rzeczy -
wszystkie PDF-y, jakie widzisz gdziekolwiek, są tworzone
"automatycznie". I nie ma żadnego znaczenia, czy generatorem jest
Distiller, Ghostscript, ps2pdf czy co innego.
>
> > istnieje wcale niemałe prawdopodobieństwo, że PDF co prawda da się
> > obejrzeć i wydrukować na drukarce, ale np. nie uda się go naświetlić...
>
> Hmmm... bo ? Zły format ? Zły rozmiar ? Przeciez wszystko jest
> konfigurowalne.
Nie. Bo będzie zawierał wadliwy element w postaci nieprawidłowego
fontu, źle skonstruowanego rysunku (EPS) lub coś podobnego. Albo też
będzie zawierał cechy, których RIP naświetlarki nie będzie umiał
zinterpretować.
> Tak na marginesie: jesli okaże się ze problemem będzie rozmiar to zmiana
> rozmiaru to jakieś 20 sekund. Automatyka zadba o ponowny skład w/g
> nowych norm.
Jak zwykle widzisz w tym, o czym piszę, coś, czego nie napisałem...
Gdzie było coś o formatach?
Zaczyna mnie to fascynować. Co jeszcze można zobaczyć w moim tekście,
o czym nie wiem?
[ciach na temat TeX - nie jestem użytkownikiem ani tym bardziej
fanatykiem TeX-a, ale mam dziwne przekonanie, że piszesz bzdury...]
> Tex tak, ale jako warstwa pośrednia pomiędzy xml a ksiązką. I tylko
> jesli to jest niezbędne.
Dokładnie to ci proponowałem. Miło, że zauważyłeś ten drobny fakt.
> > TeX przynajmniej zagwarantuje ci przyzwoity wygląd końcowy oraz
> > poprawność techniczną uzyskanych plików. Przy czym ten "przyzwoity"
> > należy rozumieć jako "prawie najlepszy z możliwych".
>
> Poprawnośc techniczną zapewni mi każda metoda generacji wyglądu w sposób
> automatyczny w tym i mój xml->whatever->pdf.
No więc nie. Ani pod względem składu, ani pod względem jakości
wynikowego PDF/Postscriptu/whatever - książka składa się ze zbyt wielu
niezależnych elementów, w tym również takich, na które nie masz
żadnego lub tylko minimalny wpływ. Żadna metod nie _zagwarantuje_ ci
poprawności. Są jednak takie, które dają większą szansę - to jest np.
posłużenie się specjalizowanym i _sprawdzonym_ oprogramowaniem - oraz
takie, gdzie szansa ta gwałtownie maleje (nowy, niesprawdzony soft).
Ale 100% pewności nie będziesz miał nigdy.
Możesz tylko na koniec sprawdzić, czy na pewno jest OK. I zazwyczaj
będzie, ale nie zawsze.
Tyle, że - powtórzę to jeszcze raz (i tym razem ostatni) - ewentualne
problemy techniczne są tym, czym najmniej powinieneś się przejmować.
Pozdrawiam,
Marek W.
--
FAQ grupy pl.comp.dtp: http://dtp.art.pl/
Lista mirrorów: http://emide.neostrada.pl
"Nie pracuje dobrze ten, kto z zamiarem wykonania łopaty buduje rakietę."
Stanisław Lem.
Marek Włodarz
Sebastian Bialy napisał(a):
> blue taxi wrote:
>> jesz kupy?
>
> Ponieważ nie bywam na tej grupie regularnie to pytanie: Czy mam
> przyjemnośc z jakimś lokalnym debilem, czy też to jakiś odosobniony
> przypadek neostradowy ?
Lokalny koloryt, reszta grupy od dawna ma go w KF, więc nawet nie
zauważa. Niestety admini serwerów news bardzo powoli się dają namówić,
żeby nie przyjmować postów z anonimizerów. Ale mam sporą nadzieję, że
to się poprawi.
Aha - do dobrego tonu należy _nie cytowanie_ tego czegoś.
Tomasz Nowicki
> Pozwole sobie więc powiedziec, że ewentualny problem to kwestia gustu i
> jak najbardziej do przeskoczenia z mojej strony.
Lepiej dodaj - "wydaje mi się"
> Chodzi o słynne "fi" w Tex ?
Nie. Mówisz o ligaturach.
> >, wyrównanie świateł,
>
> Chodzi o standardowe metody analizy obrazu normalizujace histogram
> obrazu? (tak mi wynika z google).
Nie, mówisz o obróbce zdjęć.
>
> > utrzymanie
> > registru itp.)
>
> Chodzi o zwykłe wyrównanie w pionie przez rozciągnięcie?
Nie, nie, nie - naprawdę sądzisz, że można nauczyć się składu z
google'a? A pływać z lekcji w telewizji?
> Może wątpić, a ja tylko delikatnie wspomnę, że o ile mogę sobie bez
> kłopotu zrobić xml->pdf to równie bez kłopotu mogę sobie zrobić
> xml->tex. Xml to powiedzmy taki mój sposób prywatny trzymania treści i
> logicznego jej podziału. Jeśli kerning jest kluczowy to nie ma problemu
> zrobie xml->tex->pdf i będzie. Pozostałe bajery mogę zrobić również
> automatycznie bądź półautomatycznie.
Uważaj, bo w tym zapale wymyślisz kolejny program dtp ;)
> Hmmm. Są gdzieś spisane? Mam nadzieję, że nie znajdę tam haseł typu
> "spis treści piszemy fontem xxx, w odstępie 1.654mm, z kropkami
> wiodącymi ... etc" bo to akurat też kwestia gustu i estetyki którą można
> samodzielnie wypracować dla danej ksiązki.
Nie, zapoznaj się z książką, którą ci polecałem - warto.
> Jest to kwestia gustu. Tak przy okazji - dzielenie wyrazów nie jest
> trywialne ale wykonalne. Na tyle jednak niewygodne technicznie, że nie
> wiem czy aby na pewno warto je stosować. Nie jest w moim mniemaniu
> istotnym elementem.
Jesteś w mniejszości i masz przeciwko sobie przyjęte normy. Ja wiem, że
to takie elitarne, ale czy na pewno sensowne?
> Tutaj znowu pytanie czy estetyka jest podstawowym założeniem i czy
> akurat dzielenie wyrazów jest tak kluczowe dla estetyki.
W pewnych przypadkach - tak. Co więcej - czasem nie należy dzielić
(nagłówki, tytuły), a kiedy indziej - trzeba koniecznie (pełny justunek).
> Dlaczego mają się źle drukować? Tak z ciekawości co mnie może czekać:
> np. literka A nie będzie miała poprzeczki w jakimś-tam-foncie? Hmmm...
> czy to aby nie jest problem drukarni ocenić to wstępnie? Bo nie uwierzę,
> że miszczowie od DTP dają plik i modlą się żeby coś nie znikło.
Drukarnia nie sprawdzi ci poprawności drukowania symboli matematycznych
itp. Nawet nie ma obowiązku czytać książki - spodziewają się, że
dostarczyłeś sprawdzony materiał i mogą, ale nie muszą zwracać uwagi na
drobne błędy.
> Nawet jesli tekst będzie czarny np. R=0,G=0,B=0 albo C=0,M=0,Y=0,K=100%
> ? To już mi pachnie błędem drukarni. Zwracam uwagę że dokument PDF
A mi to pachnie twoim brakiem rozeznania w temacie.
> będzie _perfekcyjny_ bo stworzony automatycznie. Nie ma tam błędów typu
> "prawie czarny tekst".
Jeśli odpowiednio ustawisz w pdf profilowanie kolorów, to tak. Ale jeśli
plik będzie tak skonstruowany, że rip "automatem" skonwertuje RGB na
CMYK, to masz klasyczną kaszanę.
> Hmmm... bo ? Zły format ? Zły rozmiar ? Przeciez wszystko jest
> konfigurowalne.
Poczytaj najpierw o tym, co to jest postscript, co to jest format pdf i
jakie są trywialne problemy przygotowania do druku. A potem będzie ci
łatwiej zagłębić się w te nietrywialne.
> Widzisz. Ja jestem gatunkiem człowieka który zanim użyje narzędzia
> najpierw weźmie go pod lupę. Jak wiem, że tex ma ogromną liczbę
Skoro sam piszesz i wydajesz oraz składasz, to pewnie też redagujesz.
Dlatego pozwolę sobie na wskazówkę - narzędzie jest rodzaju nijakiego.
Dlatego w powyższym zdaniu lepiej jest użyć formy "je" zamiast "go".
Może to tylko kwestia estetyki, ale niektórzy są przywiązani do
poprawności języka.
Poza tym - skoro zamierzasz używać postscriptu, to wpierw może go
poznaj, jako narzędzie.
> Poprawnośc techniczną zapewni mi każda metoda generacji wyglądu w sposób
> automatyczny w tym i mój xml->whatever->pdf.
Pod warunkiem, że już wiesz, jak ta poprawność jest zdefiniowana. A ty
najwyraźniej nie wiesz i masz to w nosie
T.
Tomasz Nowicki
> Ja tam widzę, że wręcz przeciwnie - wszyscy Ci mówią, że nie masz
> pojęcia a Ty idziesz w zaparte ;)
Kandydat na managera? ;)
T.
Przemysław Ryk
> Ponieważ nie bywam na tej grupie regularnie to pytanie: Czy mam
> przyjemnośc z jakimś lokalnym debilem, czy też to jakiś odosobniony
> przypadek neostradowy ?
Podejrzewam, że kolejny idiota z alt.pl.dupa czy alt.pl.zbluzgaj.
Wyrżnięto motzarellę, wyrżnięto aioe.org, to z kolejnego anonymizera
debile śmiecą po grupach. Widać trzeba na pl.news.admin prosić, żeby z
x-privat też postów na grupy w hierarchii pl.* nie wpuszczali.
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Pijak jest prawdziwym filozofem, ponieważ myśli, że to świat kręci ]
[ się wokół niego. (Faldheim) ]
Tomasz Nowicki
jego pracy nie ujrzymy nigdy - chyba, że załatwi sprawę po bożemu
T.
diWhizZ
> Witam!
>
> Nie jestem dobrze obeznany z dtp. Nie na tyle, aby móc jednoznacznie
> stwierdzić czy to co chce zrobić ma sens. Jednak pewne okoliczności
> spowodowały ze musze rozważyć całkowite złożenie ksiązki pomijając
> pośredników[1].
(ciach)
pomijając eksperymenty na swoim własnym organiźmie, zacznij od:
scribus+ghostscript+profile"eci.org"
--
~ O o
<< pozdrawiam :: adrian gwizd ... :: \\ \\ \\ o o o o o [// o o
. .. ... < stabilizacja motylka to szpilka . .. ... /\\ o o o
. .. ... e-mail: wh...@op.pl \\:: \\skype:adrian_whizz ::
Marek Włodarz
Sebastian Bialy napisał(a):
> Lolalna Loja wrote:
>> Lol. Wyobraź sobie, że dzwonisz do mnie i żądasz przygotowania kodu do
>> strony. A ja Cię pytam co to jest kod i "proszę mi wyjaśnić jak to się
>> pisze". Miałbyś niezłą polewkę pewnie? ;)
>
> Zależy. Jeśli mógłbym znaleźć pojęcie "kodu strony" na milionie stron w
> internecie do bym d... nie zawracał komukolwiek w drukarni. Problem w
> tym, że co do "kompozytowego pdf" to mam jakieś 10 definicji w google i
> każda inna. Świadczy to o tym, że wiedza z zakresu dtp jest średnio
> usystematyzowana. Czytając posty nie tylko polskie ale _w ogóle_ mam
> wrażenie że każdy jest ekspertem tylko każdy inaczej. Dlatego pytam u
> źródła licząc na odpowiedź ścisłą typu: "kompozytowy pdf to zwykły pdf".
> I prawie taką otrzymałem ;)
Kompozytowy PDF to PDF zawierający wszystkie kolory, zatem "zwykły".
W pewnym sensie _każdy_ PDF można uznać za "kompozytowy" - nawet jeśli
zawiera tylko jeden kolor (jeśli praca jest czarno-biała).
Ale w języku branżowym używane jest znaczenie węższe: jest to PDF
zawierający wszystkie kolory _używane do druku danej pracy_ i _tylko_
te. Dodatkowo musi zawierać wszystkie użyte czcionki (chyba że teksty
zostały zamienione na krzywe), bitmapy muszą mieścić się w wymaganym
przedziale rozdzielczości (a ten z kolei wynika z założonej docelowo
liniatury, zatem jakości druku), a ponadto używać odpowiedniego
algorytmu kompresji, nie obniżającego jakości (albo ZIP, czyli
bezstratna, albo JPEG z wysokim współczynnikiem jakości, choć to
ostatnie może spowodować "wywrotkę" starszych RIP-ów). NIE może
zawierać "sztuczek" i efektów, które mogłyby zaszkodzić RIP-owi (a
więc animacji, dźwięków, hiperłączy, przycisków, skryptów i żadnych
innych wodotrysków, które _da się_ wstawić do PDF). Wreszcie wszystkie
elementy muszą być w jednolitej przestrzeni barwnej albo też muszą być
dla nich wskazane odpowiednie profile (które też muszą być w tym pliku
zawarte).
PDF taki może, choć nie musi, zawierać informację o pracy, linie
cięcia, znaczniki kolorów itp. Jeśli praca zawiera grafikę na spad,
PDF musi obejmować odpowiedni spad i zawierać informację o formacie
netto (TrimBox)...
Czy o czymś zapomniałem? :>
> Hmm... jak na razie po poście Marka Włodarza nie wystraszyłem się. Z
> grubsza widzę że jeśli odrzuci się pierdoły o wielkościach marginesów i
> czcionkach które są absolutnie nieznaczące technicznie to pozostaje
> tylko problem "jakiś zniekających elementów tekstu" co do których nie
> mam pewności gdzie i dlaczego mają znikać.
Jeśli użyjesz dobrych, profesjonalnie opracowanych fontów, to nie
znikną. Pytanie jeszcze, jak ich użyjesz.
Jeśli generowane przez ciebie rysunki są bitmapami, to zadbaj o to,
aby były zapisane od razu w przestrzeni CMYK. Oszczędzisz sobie sporo
kłopotu. Jeśli wektorowe - dopilnuj, aby np. nie było w nich zbędnych
lub zbyt cienkich linii (vide mój poprzedni post). Wszystkie kolory
od razu definiuj w CMYK - to też oszczędzi kłopotów. BTW - jeśli
wektorowe, to w rachubę wchodzi tylko Postscript albo PDF. Zatem
powinieneś jednak zapoznać się z _przynajmniej_ jednym z tych formatów
w znacznie większym stopniu, niż ktokolwiek z nas - bo my nie tworzymy
Postscriptu "na piechotę"...
> Tu przyznaje, że moja wiedza
> jest poniżej dna, jednak coś mi mówi, że technologia od czasów
> wynalezienia druku chyba się nieco polepszyła i aż tak źle nie jest
> żebym miał dokumencie jedno a na wydruku co innego w sposób zasadniczy.
Tu jesteś w błędzie. W pewnym sensie technologia się cofnęła - bo
faktycznie w czasach metalowych czcionek nie było możliwości, aby na
papierze znalazło się co innego, niż w składzie (no, chyba że ktoś na
gotową matrycę upuścił np. młotek...). Teraz jest to jak najbardziej
możliwe i niestety od czasu do czasu się zdarza.
Że posłużę się analogią - nawet najlepsze programy niekiedy się
wieszają - jeśli nawet same są bezbłędne (choć Dijkstra twierdził, że
nie ma programu bezbłędnego, jeśli jest dłuższy niż 3 linie kodu), to
mogą się powiesić z powodu niezależnych od nich "okoliczności
środowiskowych". Procesów tworzenia druku dotyczy to tak samo, jak
każdego innego mechanizmu informatycznego.
> Jeśli to wiedza z zakresu estetyki to nie chce jej. Bo będzie od razu 15
> opini na 10 grupowiczów.
Tu również się mylisz. Przynajmniej w zakresie elementarnym znakomita
większość powie ci to samo. Oczywiście nie w takich szczegółach, jak
wybór konkretnego kroju czy koloru, ale jeśli chodzi o _zasady_ - te
są dobrze zdefiniowane i - na ogół - przestrzegane. Oczywiście
z wyjątkiem takich amatorów, którzy wiedzą lepiej... :>
> Jesli to wiedza techniczna (np dotyząca
> możliwości technicznych maszyn) to jestem bardzo zainteresowany bo tej
> właśnie szukam.
Hm... A po co ci informacje o możliwościach technicznych maszyn? Przed
chwilą chciałeś samodzielnie i bez użycia dedykowanego oprogramowania
złożyć książkę. Teraz chcesz jeszcze sam zbudować prasę drukarską? :>
> Hmmm... a gdzie znajdę te podstawy chociaż troche spisane tak aby ocenić
> czy są faktycznie aż tak niezwykle zagmatwane.
Cóż...
Chciałbym napisać takie Windows, tylko wiesz, lepsze, bo te oryginalne
to jakoś badziewnie działają. Czy znajdę gdzieś podstawy chociaż
trochę spisane, by ocenić, czy to programowanie jest faktycznie aż tak
niezwykle zagmatwane?
Marek Włodarz
Sebastian Bialy napisał(a):
> igoR szczurka wrote:
>> ...i zabierasz się od dupy strony. :P
>
> A miałbym zając się stwierdzeniem:
>
> "Chce zrobić śliczny system budowania xml->pdf. Zrobiłem sobie na razie
> tylko projekciki marginesów i kerningu i jest zarąbiście boskie. Co dalej?"
Nie. Zacząłeś od tego, ze chcesz złożyć książkę. I o tym rozmawiamy. I
- jeszcze raz powtórzę - problemy techniczne, nieprawidłowości
składniowe PDF czy inne podobne, to twój najmniejszy kłopot.
Prawdziwy problem, to abyś tę książkę złożył _dobrze_. Abym biorąc do
ręki wydrukowany egzemplarz - na papierze nie będzie wszak widać, JAK
powstała - mógł powiedzieć "to jest dobrze zrobione".
Jasne?
Marek Włodarz
Tomasz Szafranowski napisał(a):
> Mam wrażenie, że dyskusja jest jakby o dwóch różnych rzeczach: Sebastian
> chce zrobić pdfa drukowalnego, wszyscy pozostali zaś mówią o pdfie, którego
> treść jest złożona zgodnie z zasadami sztuki dtpowsko-drukarskiej. To jakby
> nie do końca to samo.
Sebastian napisał, że chce zrobić _książkę_. I do tego się odnoszę.
Mam w nosie, w czym to będzie robił - kiedy biorę do ręki tom w
księgarni, nie zastanawiam się, w czym go robiono, tylko oceniam, czy
jest dobrze zrobiony. I aż nazbyt często mam do czynienia z takim
badziewiem, że po prostu nie jestem w stanie tego czytać, mimo
najszczerszych chęci.
Kiedyś człowiek był twardy i czytał powielaczowe odbitki książek
drugiego obiegu, których matryce powstawały na maszynie do pisania. Od
tego czasu jednak posunęliśmy się trochę do przodu i przynajmniej moje
wymagania są większe.
> I szczerze mówiąc, nie widzę najmniejszego powodu, aby Sebastianowi miało
> się to nie udać. W końcu TeX to też w pewnym sensie automat, a jakości pdfów
> generowanych z TeXa nikt nie podważa - zarówno pod względem drukowalności,
> jak i jakości składu.
Owszem, ale po pierwsze, to jest TeX, a po drugie, żeby było dobrze,
trzeba jednak ten "wsad" do TeXa _dobrze_ przygotować. Bo w TeXu też
można wyprodukować badziewie - co z tego, że _technicznie_ będzie
poprawne...
Nie wspominając o tym, że bardzo wiele z owych zasad, o których mówimy,
a których istnienie ignoruje nasz rozmówca, TeX ma po prostu
wbudowanych i stosuje je właśnie automatycznie...
> Czy jego dokument będzie dobry (w sensie - zgodny z zasadami sztuki)? To już
> chyba jakby inny problem. Ze szczątkowego opisu tego co ten automat robi,
> skłonny jestem domniemywać, że treść jego dokumentu bliższa jest "wykazowi
> kodów serwisowych do pilotów" niż "Władcy pierścieni" (ale może się mylę).
> Można taki "wykaz" (40 stronicowa tabela, 2 kolumny) zrobić po dtpowsku,
> nowocześnie, dynamicznie, interesująco? Pewnie można....
Można też zrobić go tak, że będzie nieczytelny.
Pomiędzy efektownym, "dynamicznym, interesującym" (przymiotniki można
mnożyć) składem a składem tragicznym jest całe spektrum możliwości
pośrednich i gdzieś jest (nieuchwytna, ale niewątpliwa) granica
poprawności. Chodzi o to, aby być zawsze po właściwej stronie tej
granicy...
Marek Włodarz
Przemysław Ryk napisał(a):
> Sebastian Bialy napisał(a) w poście z dnia 2007-03-28 23:57:
>> Ponieważ nie bywam na tej grupie regularnie to pytanie: Czy mam
>> przyjemnośc z jakimś lokalnym debilem, czy też to jakiś odosobniony
>> przypadek neostradowy ?
>
> Podejrzewam, że kolejny idiota z alt.pl.dupa czy alt.pl.zbluzgaj.
> Wyrżnięto motzarellę, wyrżnięto aioe.org, to z kolejnego anonymizera
> debile śmiecą po grupach. Widać trzeba na pl.news.admin prosić, żeby z
> x-privat też postów na grupy w hierarchii pl.* nie wpuszczali.
A tu jesteś w błędzie, on z x-privat nadawał już w listopadzie - i od
tego czasu mam to wpisane do KF. Nie jego - serwer. Proste i skuteczne.
Grzegorz Staniak
> Lol. Wyobraź sobie, że dzwonisz do mnie i żądasz przygotowania kodu do
> strony. A ja Cię pytam co to jest kod i "proszę mi wyjaśnić jak to się
> pisze". Miałbyś niezłą polewkę pewnie? ;)
Ty się śmiej. Mnie z uczelnianej pracowni komputerowni wyciągnął kiedyś
pewien lepiej zorientowany człowiek, zaciągnął do serwerowni, leża
i warowni tajemniczych panów adminów sieci, postawił przed nimi i powiedział
"- Ten tutaj będzie robił strony WWW dla uczelni". Na co panowie admini się
ucieszyli, bo akurat mieli inne rzeczy do roboty, i powiedzieli "- OK, to
wrzuć te strony tu jak będą gotowe". A ja na to "- A co to są strony WWW?".
Tu się lekko zdziwili, ale powiedzieli grzecznie: "- No, takie zlinkowane
dokumenty w HTMLu". A ja na to: "- A co to jest HTML?".
Nie, nie wyleciałem na zbity pysk, dostałem wydruk primera z NCSA (ktoś to
jeszcze pamięta?), README od NCSA httpd i miałem się sam dokapować co i jak.
Rok był 1993 i akurat (prawie) wszyscy jeszcze byli dziewicami w tym temacie.
Sorry za wtręty, zmykam i nie zakłócam wspominkami pouczającej dyskusji.
Podziwiam wytrwałość, swoją drogą.
> Loja
Pozdrawiam,
GS
--
Grzegorz Staniak <gstaniak _at_ wp [dot] pl>
Przemysław Ryk
> A tu jesteś w błędzie, on z x-privat nadawał już w listopadzie - i od
> tego czasu mam to wpisane do KF. Nie jego - serwer. Proste i skuteczne.
Wiesz Marek - ja ich generalnie nie odróżniam od siebie, tylko po
pierwszym występie dodaję odpowiednie regułki do scorefile Hamstera. :)
Co nie oznacza jednocześnie, że bym się zmartwił, gdyby ktoś gówniarzowi
skórę przetrzepał. ;D
--
[ Przemysław "Maverick" Ryk ICQ: 17634926 GG: 2808132 ]
[ Jeżeli chcesz być kochany, kochaj sam siebie. (Seneka) ]
Sebastian Bialy
> [ciach]
Muszę pokusić się o pewne podsumowanie ponieważ nie mam siły na
odpowiadanie indywidualne.
Przepraszam że musiałem wykazać się sporą dawką upierdliwości ale tylko
w ten sposób udało się pozyskać interesujące mnie informację. Nie
jesteście zbyt chętni do dzielenia się wiedzą ;) Ale jak widac dla
chcącego ...
Co się dowiedziałem i co w/g mnie stanowi a co nie problem:
a) Jak widzę tak naprawdę mimo postraszenia mnie wizją znikających
czcionek, etc w rzeczywistości nie wydaje mi się aby byo bardzo źle. Nie
zamierzam przecież używać nietypowych czcionek. Zawsze mogę dopytać w
drukarni co sugerują i z czym nie ma kłopotu. Może to dla
profesjonalisty śmieszne, ale przecież drukarnia wie najlepiej jaki
proces rasteryzacji posiada i jakie mam możliwości.
b) większość grupy próbuje pokazać, że największym problemem jest wiedza
tajemna dotycząca różnych elementów wyglądu i "stylu" dokumentu.
Ponieważ jako programista mam zupełnie inne poglądy na tego typu sprawy
więc wynika naturalnie konflikt priorytetów. Problem w tym, że o ile dla
profesjonalisty regulacja "światła akapitu" może mieć kluczowe
znaczenie, to dla mnie nie ma żadnego: w mojej książce na każdej stronie
jest obrazek a nieżadko dwa. Wygląda to jak ser, tyle dziur. Próba
dopasowania akapitów nie ma sensu, dokument jest nierówny z definicji.
Mało tego, preferuje nawet nierówna zakończone strony tylko w celu
zachowania logicznej ciągłości tekstu i obrazu. Może się okazać, że dla
dtpowca taki dokument jest brzydki, ale dla matematyka okaże się
_logiczną sekwencyjną całością_ w której przestawienie równania do
sąsiedniego akapitu to zbrodnia na treści. Datego też święte zasady dtp
mogę sobie głęboko wsadzić, bo to będzie co strona to wyjątek...
c) Nie widzę żadnego powodu dla którego z mojego źródła (xml) nie dało
by się wygenerować czegokolwiek. Lista mozliwości od ręki to: pdf (z
użyciem fop), word (z użyciem natywnego xml worda), tex, docbook,
openoffice itd. Każde przekształcenie jest całkowicie konfigurowalne.
Dlatego też jeśli faktycznie tex "wygląda znakomicie" to może się nim
zainteresuje jako platformą pośrednią. Ale wolałbym nie wchodzić w tex
jeśli nie będzie to warte efektu. Zobaczymy.
d) Moja grafika odbiega od typowych formatów jakie każdy z was zna. Ja
nie mam bitmap, eps-ów, wmf-ów. Ja mam obrazki w postaci źródeł. Np.
asymptote to tak naprawdę program który dopiero po wykonaniu generuje
obraz wektorowy. Może ktoś zapytać po co mi to. A ja odpowiem: bo tak
jest łatwiej, choć łatwość można zrozumieć będąc chyba tylko
programistą. Dla przeciętnego zjadacza chleba to jest niepojęte i
niezrozumiałe utrudnienie. Dla mnie ułatwienie, bo mogę taki rysunek
dowolnie przekształcać, zmieniać, powielać w dokumencie, tworzyć ogromne
ilości odmian i kontrolować powtarzające się elementy. Jednak wniosek
jest oczywisty: mogę w docelowym dokumencie te obrazy wygenerować jak
bądź: do tiff, ps, bmp, svg, whatever. Nie ma znaczenia bo ja kontroluje
końcowy format. Włącznie z tą magiczną separacją/kompozycją CMYK bez
której drukarnie jak widze nie mogą się obejść.
e) Dodatkowe pseudo trudne pojęcia jak inpozycja, spady itd to tak
naprawdę albo elementy którymi ma zająć się drukarnia i mnie nie
interesują, albo też mogę sam je zasymulować w docelowym dokumencie.
Tak, mogę. Podkreślam to. To tylko kwestia zmiany metody generacji
dokumentu, dodania skryptu, whatever. Technicznie wykonalne. Choć
oczywiscie znajdzie się wielu sceptyków twierdzących że skoro to takie
proste to czemu tego już nie ma. Ano nie ma i powodów nie znam. No chyba
że ktoś pytał wczesniej na grupie i go zniechęcono...
f) Uwagi, że niby robie coś lepszego od Adobe'a są całkiem trafne. Ja
już epokę "wygody klikania" mam za sobą. Teraz żądam czegoś
wygodniejszego: automatyzacji, skryptów budujących, systemów kontroli
wersji itp. Internet jest pełen pojedynczych klocków z których można
zbudować pracujacy system dtp który w oczach "zawodowca" będzie wyglądał
jak przyszczerska konsola "w gupim linuxie". Jednak dla mnie jest to
100x wygodniejsze od klikania w adobe/quark/whatever. Zaznaczam: dla
mnie. Nie zamierzam nikogo nawracać.
g) Nie mogę pokazać "chociaż jednej strony w pdf". Ja po prostu go nie
mam jeszcze. Własnie po to piszę na grupę, żeby okazało się, czy włożona
praca w ten system ma sens. Na razie to zlepek pomysłów (sprawdzonych i
przetestowanych z których korzystam w innym celu), jednak nie jest
funkcjonalny. I nie będzie w najbliższym czasie. Co nie zmienia faktu że
nie opowiadam bajek: każdy element tego systemu już gdzieś
implementowałem i wiem jakie mam ograniczenia techniczne i jakie
dostepne możliwości. I wiem doskonale że powstanie całości jest tylko
kwestią casu a nie przeszkód technicznych.
h) Dzielenie wyrazów okazuje się tak ważne, że zastanawiam się czy aby
nie ważniejsze od treści ;) Niestety mojego poglądu że to kwestia gustu
nie zmienie. Jak również tego że czytam teks nie podzielony szybciej.
Ale może jestem inny.
i) Nie wiem skąd tyle krytycznych uwag, jednak mam nadzieje że wynikają
one z niezrozumienia moich potrzeb a nie "życzliwości"... Ja nie piszę
ksiązki humanistycznej którą można łatwo obrobić za pomocą jakiegoś
gotowego programu. Jeśli ktoś z was składał książki techniczne (np prace
naukowe), to wie, że tam często są dośc skomplikowane systemy
odnośników. Ja mam odsyłacze do: tabel, obrazków, równań, wykresów,
schematów, rodziałów, cytatów, twierdzeń, definicji i pewno jeszcze 5
innych rzeczy - wszystkie osobno numerowane. Jedne numeruje się siak,
inne inaczej. I to tylko jeden z wielu systemów automatyki w dokumencie.
Zapanowanie nad tym podczas składu jest trudne, tym bardziej, że mogę
mieć wymóg zrobienia takiej numeracji inaczej niż wydawało się twórcom
MS Office/quark. Oczywicie nie muszę mówić, że odsyłacze są
automatycznie aktualizowane. Dlatego tak niezykle silnie upieram się
przy automatyzacji składu moimi narzędziami. Ja mogę sobie zrobić rzeczy
których nie da się zrobić inaczej. I dlatego traktuje worda jako tylko
edytor tekstowy. Bo niczym więcej nazwać go nie mogę.
j) xml pozwala mi po zastosowaniu pewnego zbioru zasad stworzyć
dokumenty BEZBŁĘDNE. Już widze ten uśmiech, jednak zaznaczam, że jeśli
wie sie jak to zrobić to nie ma takiej możliwości abym zapomniał o
podpisie rysunku, wpisał podrodział bez rodziału, zapomniał nazwać
tabeli czy wpisał cytat nie podając autora. Takie zbiory reguł są na
tyle silne że dokument nie przejdzie walidacji. Więc źródło mojego
dokumentu jest perfekcyjne i pewne. Oznacza to również (pomijając błedy
w oprogramowaniu) że docelowy dokument jest również perfekcyjny. Mam na
myśli podziały logiczne dokumentu, powtarzalnośc wyglądu styli itp. Może
nie być zgodny ze sztuką dtp ale nikt nie nie może zarzucić że gdzieś
akapit się zrobił mniejszy. Nie ma prawa. To nie zabawka typu Word.
k) zdaje sobie sprawę, że poprawny skład kolorystyczny jest kluczowy.
Zaznaczam jednak, że prawdopodobnie pierwsza wersja będzie cz-b. Powinno
to znacznie powyższyć moje szanse na zrobienie tego ok od razu. A wyzwań
się nie boję.
l) Podczas tworzenia kolorowych plakatów, ulotek, etc zapewne istnieje
ogromny zbiór zasad pozwalajacy uzyskiwać poprawne odwzorowanie barw
(choć od razu mówie, że widziałem już pare źródeł i wyników i widzę, że
profesjonalne pojęcie precyzji jest baaaaardzo rozciągliwe ;). U mnie
jeśli kolor żółty będzie miał lekko pomarańczowy kolor to przeżyje. To
tylko schemat. Nie tragizowałbym wiec problemów z barwami bądz separacji
CMYK. To nie ten rodzaj grafiki. Nie robie albumu malarstwa.
m) Uważam (na podstawie waszych wypowiedzi )że technologia stosowane
przez drukarnie to średniowiecze (w świetle przedstawionych tutaj
problemów). Od razu zaznaczam, że mój pogląd wymaga z demokracji, bo
mogę. Nie wyobrażam sobie, aby oprogramowanie na drukarni mogło mi
inaczej wydrukować obraz niż ten który dostarczam w postaci dokumentu.
Jesli takie coś ma mmiejsce to albo dokument jest popieprzony (co u mnie
nie wystąpi bo automatyka nie generuje przypadkowych elementów w
dokumencie) albo drukarnia ma za stare/do dupy oprogramowanie. Wtedy im
podziękuje. Nie mogę rozwiązywać problemów drukarni. Niech sami sobie je
rozwiązuja.
n) <złośliwie>proces RIPowania wygląda na tyle skomplikowanie, że
zastanawiam się czy aby na pewno to zamiana krzywych i bitmap na punkty.
Może tam jeszcze jest w algorytmach jakiś random() skoro 2007 roku są
problemy z wydrukiem fontów osadzonych w dokumencie?</złośliwie>. Czy
aby środowisko DTP nie powinno zawalczyć w kierunku poprawy tego zamiast
twierdzić usilnie że to jest w porządku tylko ja jestem głupi.
Nie chciałem nikogo urazić/obrazić. Jestem po prostu człowiekiem, który
na profesjonalnym DTP nie zna się, jednak chce coś samodzielnie
zdziałać. Nie jestem idiotą z neostradą i piszącym programy w delphi.
Znam się wystarczająco szeroko na informatyce żeby wiedzieć jakimi
metodami osiągnąc cel i wiem że te metody będą/są skuteczne. Chce jednak
wiedzieć jakie przeszkody napotkam po drodze natury nieinformatycznej.
Pytanie nie boli, choć pado tutaj wiele godnych pożałowania nadętych
sformułowań (w tym z mojej strony również). Jednak cel udało się
osiągnąć: wiem więcej - za co dziękuję.
Chciałbym serdecznie pozdrowić obydwa obozy (zarówno totalnych sceptyków
sądzących że jestem samobójcą jak również luzaków twierdzących aby
drukować i mieć wszystko w d...) i prosić o więcej, jesli coś pominąłem
i wymaga dodatkowego wyjasnienia.
Bez urazy.
Pawel Nawrocki
> Muszę pokusić się o pewne podsumowanie... [ciach]
Podsumowanie nastąpi, kiedy przedstawisz wszytkim do wglądu próbkę tego
Twojego BEZBŁĘDNEGO dokumentu...
Powodzenia, czekam intensywnie ;)
Pozdrawiam
PN
Sebastian Bialy
> Podsumowanie nastąpi, kiedy przedstawisz wszytkim do wglądu próbkę tego
> Twojego BEZBŁĘDNEGO dokumentu...
Fak że w to wątpisz świadczy o Twoim braku pojęcia co to jest DTD.
Proponuje zacząć kształcenie od:
http://en.wikipedia.org/wiki/Document_Type_Definition
Zapewniem Cię, że jesli prawidłowo zdefiniuje DTD (co jest trywialne)
dokument po prostu nie może zawierać błędów bo zostanie odrzucony na
etapie analizy i walidacji. To jest jak stwierdzenie że 2+2=4. Jest
zawsze spełnione bez względu na sceptycyzm czytelnika. Każdy inny wynik
wygeneruje błąd walidatora. Oczywiście mowa wyłacznie o błedach
logicznych xml a nie ortograficzno/stylistycznych w treści[1]. DTD nie
analizuje treści a jedynie pewne definiowane przeze mnie zależności w
drzewach znaczników. Ale to własnie dlatego nie wystąpi ani jeden
rysunek bez podpisu czy tabel bez nazwy. To jest niemożliwe. Stąd moje
przekonanie o bezbłędności. Choć potrafi zrozumieć, ze mając do
czynienia z codziennymi dokumentami w Word można mieć wątpliwości.
> Powodzenia, czekam intensywnie ;)
Możesz się nie doczekać jeśli zrezygnuje z projektu. To ciągle jest
bardziej koncepcja niż działający mechanizm.
[1] Co w niczym nie przeszkadza dodać mechanizmu tego typu jako jednego
z kroków składu.
Marek Włodarz
Sebastian Bialy napisał(a):
> Pawel Nawrocki wrote:
>> Podsumowanie nastąpi, kiedy przedstawisz wszytkim do wglądu próbkę tego
>> Twojego BEZBŁĘDNEGO dokumentu...
>
> Fak że w to wątpisz świadczy o Twoim braku pojęcia co to jest DTD.
>
> Proponuje zacząć kształcenie od:
>
> http://en.wikipedia.org/wiki/Document_Type_Definition
>
> Zapewniem Cię, że jesli prawidłowo zdefiniuje DTD (co jest trywialne)
> dokument po prostu nie może zawierać błędów bo zostanie odrzucony na
> etapie analizy i walidacji.
Problem w tym, że twój proces weryfikacji (w słowniku języka polskiego
nie ma słowa "walidacja"...) nie zawiera niemal żadnej z tych cech,
które my uznamy za błąd.
Ale życzę powodzenia. I pokaż, co wyszło... :>
Sebastian Bialy
> Problem w tym, że twój proces weryfikacji (w słowniku języka polskiego
> nie ma słowa "walidacja"...) nie zawiera niemal żadnej z tych cech,
> które my uznamy za błąd.
Natomiast wasze procesy weryfikacji nie zawiera żadnych cech które ja
uznaję za błąd a co najwyżej za inny gust. I dlatego mamy konflikt
priorytetów o którym wspomniałem. Dla mnie poprawny układ logiczny jest
ważniejszy niż drobnostki typu wycięcia akapitowe czy światła akapitów.
> Ale życzę powodzenia. I pokaż, co wyszło... :>
_Jeśli_ podejmę się tego to nie omieszkam.
gravide
news:euk7jl$oq6$1...@nemesis.news.tpi.pl...
> Natomiast wasze procesy weryfikacji nie zawiera żadnych cech które ja
> uznaję za błąd a co najwyżej za inny gust. I dlatego mamy konflikt
> priorytetów o którym wspomniałem. Dla mnie poprawny układ logiczny jest
> ważniejszy niż drobnostki typu wycięcia akapitowe czy światła akapitów.
Tia... jak Ci się 500 stron A4 czarnego tekstu rozbarwi na cztery
płyty, to inaczej będziesz śpiewał... przy płaceniu rachunku...
Wspomniałeś, że pewnie mamy Cię za samobójcę...absolutnie...
Na takie działanie są mocniejsze słowa...
pozdrawiam i życzę powodzenia
grav
InDesign Scripts
> płyty, to inaczej będziesz śpiewał... przy płaceniu rachunku...
> Wspomniałeś, że pewnie mamy Cię za samobójcę...absolutnie...
> Na takie działanie są mocniejsze słowa...
no to tutaj musze branic Białego ;)
przeciez on pisze, ze ma kontrolne nad skladowymi CMYK w tekscie i obiektach - wiec nic mu sie zle nie rozbarwi ;)
robin
--
Skrypty do AdobeFamily
www.adobescripts.pl
gg 3753393
tlen robinet
ICQ 20057375
Skype: AdobeScripts
a889
news:euk3u8$g5v$1...@atlantis.news.tpi.pl...
> Muszę pokusić się o pewne podsumowanie ponieważ nie mam siły na
> odpowiadanie indywidualne.
[ciach]
Nie mam czasu odpowiadać szczegółowo. Odpowiem tak - takich bzdur już dawno
nie czytałem, i dawno nie miałem o czynienia z tak zarozumiałym człowiekiem.
Teraz zaczynam rozumieć kawały o informatykach...
Sebastian Bialy
> Nie mam czasu odpowiadaæ szczegó³owo. Odpowiem tak - takich bzdur ju¿ dawno
> nie czyta³em,
Wiesz, jeśli nie masz czasu to mógłbyś podać chociaż _jeden_ przykład.
Miałbym na co odpowiedzieć, z czym polemizować czy tez zastanowić się. A
tak to tylko zmarnowałeś pare bitów na stwierdzenie nic nie wnoszące do
dyskusji.
> i dawno nie mia³em o czynienia z tak zarozumia³ym cz³owiekiem.
Jak nazwać człowieka który w połowie rozmowy zabiera głos po raz
pierwszy i od razu mówi "bzdury" i wychodzi ? Hmmm... ja staram się
przynajmniej w jakiś sposób uzasadniać swoje poglądy i stwierdzenia pod
kątem techniczno-informatycznym oczywiście bo na tym się znam. Uważam,
że jeśli jestem zarozumiały to nie bardziej niż Ty w tym poście.
> Teraz zaczynam rozumieæ kawa³y o informatykach...
Dawaj śmiało. Zawsze to dobrze pośmiać się z siebie.
PS. Fakt, nie przyszedłem tu błagać o wiedzę na kolanach tylko
dyskutować i dopytywać i być może przestawić swoje argumenty. Taki styl
dyskusji własnie mi odpowiada. Jeśli to komuś przeszkadza to serdecznie
przepraszam. Nie ma obowiązku ze mną dyskutować.
Bez urazy.
Pawel Nawrocki
>> Ale życzę powodzenia. I pokaż, co wyszło... :>
> _Jeśli_ podejmę się tego to nie omieszkam.
Pozwolisz, że przytocze jeszcze jedną Twoją wypowiedź:
> Możesz się nie doczekać jeśli zrezygnuje z projektu. To ciągle jest
> bardziej koncepcja niż działający mechanizm.
Załozyłem się z kumplem, że podasz logiczny i sensowny powód, dzięki
któremu nikt nigdy nie zobaczy Twojego BEZBŁĘDNEGO dokumentu. W naszym
zawodzie błędy bardzo szybko odczuwamy w portfelu, więc jesteśmy żywo
zinteresowani BEZBŁĘDNYMI dokumentami. Ale skoro to, co tak namiętnie i
żarliwie opisywałeś, jest tylko i wyłącznie teorią, niepopartą żadnym
konkretnym przykładem... zajmij się polityką, tam nikt od Ciebie nie
będzie wymagał potwierdzenia Twoich teoretycznych rozważań - a jeżeli
już, to wystarczy porządna ściema dla Twojego elektoratu. I proszę mi
nie wyskakiwać z tekstami w stylu: "błogosławieni Ci, którzy nie
widzieli a uwierzyli..." - my na tej gruppie jesteśmy użytkownikami, a
nie wyznawcami :P
Pozdrawiam
PN
PS. Mam prośbę do Ciebie - dopóki nie poprzesz swoich teorii konretnymi
przykładami, dopisuj w temacie Twoich watków [SF]
gravide
news:eultet$h99$1...@nemesis.news.tpi.pl...
> Hmmm... ja staram się
> przynajmniej w jakiś sposób uzasadniać swoje poglądy i stwierdzenia pod
> kątem techniczno-informatycznym oczywiście bo na tym się znam. Uważam,
> że jeśli jestem zarozumiały to nie bardziej niż Ty w tym poście.
Ale to nie jest grupa o informatyce.
99% bywalców grupy to praktycy DTP.
Ty jesteś teoretykiem który stworzył model idealny.
Jak tu zachować powagę? Jak argumentować?
Chcesz zobaczyć nadroższy wagon makulatury na świecie?
Wydrukuj swoją ksiażkę po swojemu.
pozdrawiam
grav
a889
news:eultet$h99$1...@nemesis.news.tpi.pl...
> Wiesz, jeśli nie masz czasu to mógłbyś podać chociaż _jeden_ przykład.
> Miałbym na co odpowiedzieć, z czym polemizować czy tez zastanowić się. A
> tak to tylko zmarnowałeś pare bitów na stwierdzenie nic nie wnoszące do
> dyskusji.
Możliwe. Jednak cały ten wątek nie wnosi praktycznie nic w temacie DTP.
> Jak nazwać człowieka który w połowie rozmowy zabiera głos po raz pierwszy
> i od razu mówi "bzdury" i wychodzi ? Hmmm... ja staram się przynajmniej w
> jakiś sposób uzasadniać swoje poglądy i stwierdzenia pod kątem
> techniczno-informatycznym oczywiście bo na tym się znam. Uważam, że jeśli
> jestem zarozumiały to nie bardziej niż Ty w tym poście.
Mam sporo pracy i po prostu nie mam czasu na pisanie i czytanie
teoretycznych wywodów, które nikomu do niczego nie są potrzebne. Jestem
praktykiem - nie teoretykiem. Składam książki, robię projekty graficzne i
cenię swój czas. Na grupę piszę, jeśli mam jakiś problem, a nie - żeby sobie
poteoretyzować. Zamiast wypisywać posty o kilkuset linijkach, używam
odpowiednich narżedzi, żeby wykonać konkretną pracę, np. złożyć książkę. I
Tobie też radzę. Nie trzeba konstruować samochodu, żeby pojechać na zakupy.
> PS. Fakt, nie przyszedłem tu błagać o wiedzę na kolanach tylko dyskutować
> i dopytywać i być może przestawić swoje argumenty. Taki styl dyskusji
> własnie mi odpowiada. Jeśli to komuś przeszkadza to serdecznie
> przepraszam. Nie ma obowiązku ze mną dyskutować.
>
> Bez urazy.
Bez urazy, ale czy nie szkoda Ci czasu? Musiałeś spędzić już w sumie ładne
kilkanaście godzin nad swoimi wypowiedziami w tym wątku. I co? Nic.
Sebastian Bialy
> Mo¿liwe. Jednak ca³y ten w±tek nie wnosi praktycznie nic w temacie DTP.
Mi wnosi. A czy innym - nie wiem. Jesli ktoś uważa to za stratę czasu to
niech sobie omija watek.
> Bez urazy, ale czy nie szkoda Ci czasu? Musia³e¶ spêdziæ ju¿ w sumie ³adne
> kilkana¶cie godzin nad swoimi wypowiedziami w tym w±tku. I co? Nic.
Kinkanaście minut. I nie nic. Mam konkrety. Wiem więcej. Mało tego, nie
udało się nikomu mnie wystraszyć na tyle bym porzucił pomysł na dobre.
Sebastian Bialy
> Ale to nie jest grupa o informatyce.
Wiem. Dlatego używam ogólników nie wnikając w mechanizmy działania w
szczegółach. Nie zamierzam zanudzać budową xmla czy transformacją xsl bo
to nie jest ta tematyka.
> 99% bywalców grupy to praktycy DTP.
Którzy używają narzedzi informatycznych. Dlatego uważam tematykę za
uzasadnioną. Gdzie indziej znajdę fachowców potrafiących wskazać
problemy techniczne z wydrukami? Jesli jest inna grupa natychmiast się
przeniosę.
> Ty jesteś teoretykiem który stworzył model idealny.
Nie. Stworzyłem dokument źódłowy idealny (wszystkie walidujące się
xml+dtd są idealne). Jego wygląd docelowy może być jednak nieidealny bo
DTP to nie matematyka - jest wiele poglądów i gustów niekoniecznie
zbieżnych. Dokument źródłowy jest świetnie doipasowany do moich potrzeb
(i paru innych osób które mają podobne problemy). Dlaczego miałbym
porzucić wszystko co mogę nim zrobić i przechodzić katusze choćby z
Wordem? Z resztą on nie jest tematem dyskusji: tematem jest możliwe
automatyczne wygenerowanie pdf zjadliwego dla drukarni bez używania
drogiego oprogramowania. Wydaje mi się, że znam metodę i środki.
Dopytuje o szczegóły aby przed czasem poznać problemy.
> Jak tu zachować powagę? Jak argumentować?
Na pewno inaczej niż "bzdury". Lub nie komentować. Przecież nie zmuszam
nikogo do odpowiadania. Grzecznie prowadzę dyskusję choć dostałem już
parę razy po głowie pałką.
> Chcesz zobaczyć nadroższy wagon makulatury na świecie?
> Wydrukuj swoją ksiażkę po swojemu.
Na szczeście nie jestem pesymistą ;) A wagonów makulatury (pod kątem
technicznym, językowym i tłumaczenia) to ja widze codziennie dziesiątki
w empiku i nikt nie drze szat.
a889
> Kinkanaście minut. I nie nic. Mam konkrety. Wiem więcej. Mało tego, nie
> udało się nikomu mnie wystraszyć na tyle bym porzucił pomysł na dobre.
Nie ściemniaj. Kilkanaście minut to zajęło Ci pisanie jednego posta. A
napisałeś ich dokładnie 20.
Według mnie, nie ma szans, żebyś zrealizował swój "projekt". To tylko takie
gawędziarstwo... Internetowe lanie wody.
Stefan Nawrocki
> a889 wrote:
>> Mo?liwe. Jednak ca3y ten w?tek nie wnosi praktycznie nic w temacie DTP.
>
> Mi wnosi. A czy innym - nie wiem. Jesli ktoś uważa to za stratę czasu to
> niech sobie omija watek.
Dyskusja, którą próbujesz prowadzić wg mnie jest bez sensu i chyba jednak
niczego z niej nie wyniosłeś.
Jeśli pytasz, czy da się napisać konwerter z jednego formatu na inny - to
oczywistym jest, że taki konwerter da się napisać. I do tego nie trzeba
zawracać głowy grupie. Oczywistym jest też że jeśli ten konwerter będzie
idealny, to dane na wyjściu (u Ciebie pdf) będą dokładnym odzwierciedleniem
tego co masz na wejściu (u Ciebie xml). Więc po co ta dyskusja?
Jeśli konwerter oprócz konwersji będzie robił inne rzeczy - to już nie
będzie to konwerter. I teraz mamy dwie możliwości - albo będzie pewne
informacje gubił - to będzie wada konwertera, albo - druga możliwość -
będzie wnosił jakąś swoją "wartość dodaną" - np. inteligentne prowadzenie
tekstu celem uzyskania jak najlepszych świateł w akapicie. Jednak te
"wartości dodane" Ciebie nie interesują - o czym wielokrotnie tu pisałeś. Wg
mnie - takie podejście dyskwalifikuje Twój projekt. To - czego brakuje w
branży dtp - to właśnie inteligentnego wspomagania składacza w zbliżaniu się
do składu "idealnego". To jednak po pierwsze nie jest zadanie dla
konwertera, po drugie Ty nie jesteś zainteresowany poprawianiem jakości
składu.
Pozdrawiam
Stefan Nawrocki
www.3n.com.pl
Sebastian Bialy
> Ale skoro to, co tak namiętnie i
> żarliwie opisywałeś, jest tylko i wyłącznie teorią, niepopartą żadnym
> konkretnym przykładem...
Dobrze. Więc _konkretny_ przykład który z resztą już tu raz padł
(wystarczyło użyć google). Nie mój, jest to jeden z istniejących i
działających systemów składu dokumentów ze źródłami w xml (i sam
napisany w xml/xsl). Oddaje on większość elementów które ja chcę
implementować/implementuje aktualnie. I jest dokładnie w takiej samej
filozofii jak to co chce zrobić.
Nazywa się DocBook.
Znajdziesz tam wyczerpujące informacje o jego budowie i możliwościach.
Pozwole sobie jednak częsciowo je przybliżyć:
a) Walidowalnośc dokumentu. Nie uda ci się spieprzyć czegokolwiek w
logicznym układzie. Nie da się, docbook go nie zaakceptuje. To jest
bardzo dobra cecha, której tak brakuje typowym edytorom typu Word.
b) Supportuje MathML (równania matematyczne w xml) oraz SVG a więc
najważniejsze dla mnie dwa elementy graficzne.
c) generuje wiele targetów: pdf, worda, texa i masę innych.
d) Jest absolutnie i bezdyskusyjnie dowolnie konfigurowalny. Jest to
jednak praca dla osoby obeznanej w xml i xsl dlatego nie jest popularny
wśród osób innych niż programiści. Stąd zapewnie niewielu z Was o nim
słyszało.
Brakuje mu jednak sporej ilości elementów (specyficznych dla mnie)
takich jak kompilacja rysunków w locie i ładny wygląd. Bo mówiąc
szczerze, wygląd pdf dokumentu docbook jest taki sobie. Wszystko jest
jednak modyfikowalne w dowolnym zakresie poprzez zmiane transformacji
xsl. W sume nawet dośc prosto. Nie wiem też czy wypluwane przez niego
pdfy są dobrej jakości technicznej dla przeciętnej drukarni. Ponieważ ja
będę generował je identycznie (w sensie metody), to pozwoliłem sobie o
pytania na grupie w celu ustalenia problemów które mogę wystąpić.
Przykład wyglądu źródła docbook można zobaczyc na:
http://xml.web.cern.ch/XML/goossens/dbatcern/hello-world.html#d0e350
> "błogosławieni Ci, którzy nie
> widzieli a uwierzyli..." - my na tej gruppie jesteśmy użytkownikami, a
> nie wyznawcami :P
Raczej nie będzie to potrzebne. Zerknij na DocBooka i mam nadzieję żenie
będziesz szukał teori spiskowej że stronę tą popełniłem na potrzeby
zadziwnienia grupy.
> PS. Mam prośbę do Ciebie - dopóki nie poprzesz swoich teorii konretnymi
> przykładami, dopisuj w temacie Twoich watków [SF]
Sugeruje poszerzenie horyzontów i lekkie wyluzowanie. Nie wiesz
wszystkiego, nawet z DTP. Podobnie jak ja z programowania. Dlatego nie
wypowiadam się, że coś nie istnieje, bo może się okazać że nie widziałem
jeszcze wszystkiego.
Zapewne usłyszę zaraz hasło, że to nie moje. No więc dobrze. Posklejałem
na szybkow wieczorem co miałem pod ręką. Wyszedł prymitywny system
produkcji pdf ze źródeł xml wykorzystujący po drodze docbook z moim
podstawowym założeniem: kompilacją w locie rysunków. Z braku czasu nie
ma polskich znaków (instalacjia w fop jest upierdliwa, choć oczywiście
możliwa) i wrzuciłem co miałem pod ręką. Wygląd jest obleśny ale
obrazuje idee: moje źródło jest nietypowe i nic tu quark nie poradzi.
Przykłady to:
dokument źródłowy:
http://155.158.112.170/book.xml
dokument wynikowy:
Cały proces odbywa się w konsoli i został uruchomiony na serwerze
linuxowym. Identycznie można na widnowsie. Nie kliknąłem myszką ani razu.
Zwracam uwagę na najwazniejszą rzecz: plik book.xml jest całkowicie
wystarczalny do wygenerowania pliku x.pdf. Rysunki są w formie źródeł a
nie w plikach zewnętrznych.
Proszę nie oceniać tego pod kątem DTP - nie mam teraz czasu na zabawę w
ładne wyglad czy CMYK. To jest robione na żywo, bylejak poskładane z
tego co mam. Ale działa i obrazuje idee składu tekstu całkowicie
automatycznie zgodnie z moimi postulatami.
Mam nadzieje, że to zaspokoi problem _zakładu_ lub przynajmniej zasiele
ziarnko niepewności. Prosze następnym razem nie oceniaj ludzi zbyt
pochopnie.
Oczywiście od tego co jest jest daleka droga to poprawnego dokumentu
pdf. Ale proszę nie mów mi, że to teoria. Poskładałem w jeden wieczór
namiastkę praktyki.
PS. Prosiłbym o nie hihotanie zbyt głośne na widok źródła xml. Zadaniem
xml jest coś zupełnie innego niż wygoda tworzenia dokumentu. Jest nim
separacjia logiki od wyglądu. I na przykład w moim przypadku jest to
bardzo ważny element który ułatwia mi pracę.
a889
> dokument wynikowy:
>
> http://155.158.112.170/x.pdf
Super. Widzę, że najbardziej rajcuje Cię to, że konsola, linux, pełna
elastyczność. A tymczasem w pdfie posypały się polskie litery :))) A to
dopiero poczatek.
Sebastian Bialy
>>http://155.158.112.170/x.pdf
> Super. Widzê, ¿e najbardziej rajcuje Ciê to, ¿e konsola, linux, pe³na
> elastyczno¶æ.
Nie rajcuje. To mi pomaga w pracy. Jedni lubią pisać swoje dokumenty w
pliku a ja wole mieć je w systemie kontroli wersji. Jedni lubią klikać 3
godziny ustawiając akapity a ja wole określić w pliku że mają półtora
znaku. Etc. Jestem programistą, pamiętasz? To znaczy że jestem świrem
ułatwiającym sobie życie. To mnie nie rajcuje. To mi pomaga.
> A tymczasem w pdfie posypa³y siê polskie litery :))) A to
> dopiero poczatek.
O czym wspomniałem aby nikt nie wyskoczył z takim hasłem. Widać
następnym razem napiszę to wielkimi literami potrzykroć.
a889
>> A tymczasem w pdfie posypa3y sie polskie litery :))) A to dopiero
>
> O czym wspomniałem aby nikt nie wyskoczył z takim hasłem. Widać następnym
> razem napiszę to wielkimi literami potrzykroć.
Nie o to chodzi. Chodzi o to, że program robi źle to do czego został
stworzony. Przez to jego funkcjonalność jest żadna. A co do klikania -
podczas 3 godzin kilkania mogę spokojnie złożyć książkę w InDesignie lub
Quarku. Potem korekta, poprawki i można dać do druku. A Ty jak zamierzasz
przeprowadzać korektę?
Sebastian Bialy
> Je¶li pytasz, czy da siê napisaæ konwerter z jednego formatu na inny - to
> oczywistym jest, ¿e taki konwerter da siê napisaæ. I do tego nie trzeba
> zawracaæ g³owy grupie. Oczywistym jest te¿ ¿e je¶li ten konwerter bêdzie
> idealny, to dane na wyj¶ciu (u Ciebie pdf) bêd± dok³adnym odzwierciedleniem
> tego co masz na wej¶ciu (u Ciebie xml). Wiêc po co ta dyskusja?
Postraszono mnie, że mogą pojawić się jakies dodatkowe elementy, zniknąć
istniejące. Dopiero po paru postach wywnioskowałem (aczkolwiek dalej nie
w prost) że dotyczy to niechlujnie przygotowanych pdfów a nie pdfów w
ogóle. A więc jednak coś się dowiedziałem. Moim zdaniem mam teraz
większą wiedzę niż przed.
> Je¶li konwerter oprócz konwersji bêdzie robi³ inne rzeczy - to ju¿ nie
> bêdzie to konwerter.
Bo to nie jest konwerter. To system gdzie skład tekstu jest tylko
finalnym krokiem. I o ten finalny krok pytałem starając się możliwie nie
wnikać w szczegóły. Niestety nie dało się. Musiałem się w końcu
wyspowiadać o co mi chodzi mimo ostrych słów krytyki, często krytyki
nietrafionej.
> I teraz mamy dwie mo¿liwo¶ci - albo bêdzie pewne
> informacje gubi³ - to bêdzie wada konwertera, albo - druga mo¿liwo¶æ -
> bêdzie wnosi³ jak±¶ swoj± "warto¶æ dodan±" - np. inteligentne prowadzenie
> tekstu celem uzyskania jak najlepszych ¶wiate³ w akapicie. Jednak te
> "warto¶ci dodane" Ciebie nie interesuj± - o czym wielokrotnie tu pisa³e¶.
Niekoniecznie: jesli są opisywalne matematycznie to kto wie czy nie
można ich wbudować. Obawiam się jednak że sztuka składu DTP jest w
pewnym sensie nieopisywalna matematycznie. Dlatego muszę świadomie z
tych elementów zrezygnować, bo sa one nieimplementowalne.
> Wg
> mnie - takie podej¶cie dyskwalifikuje Twój projekt. To - czego brakuje w
> bran¿y dtp - to w³a¶nie inteligentnego wspomagania sk³adacza w zbli¿aniu siê
> do sk³adu "idealnego".
Jesli znajdę matematyczną defninicję składu idealnego to nie widzę
przeszkód aby takie narzędzie mogło za jakiś odległy czas powstać w tym
co mam/będę miał. Jesli taka definicja nie istnieje, to nigdy nie powstanie.
> To jednak po pierwsze nie jest zadanie dla
> konwertera,
To nie jest TYLKO konwerter. To wiele mechanizmów tworzących razem coś
zamieniające xml w pdf. Po drodze jest automatyczny skład, ale to jeden
z elementów. Ja jestem zainteresowany przede wszystkim problemami na
styku pdf->drukarnia i możliwością ich automatycznego usuwania.
> po drugie Ty nie jeste¶ zainteresowany poprawianiem jako¶ci
> sk³adu.
Dokładnie. Jestem zainteresowany wydrukowaniem tego co mam w posób taki,
aby uniknąc kłopotów. To że dyskusja potoczyła się w kierunku całkiem
odmiennym to nie jest do końca tylko moja wina.
Sebastian Bialy
> Nie o to chodzi. Chodzi o to, ¿e program robi ¼le to do czego zosta³
> stworzony. Przez to jego funkcjonalno¶æ jest ¿adna.
Bo i też powstał w 3 godziny poskładany z czego miałem pod ręką. Nie
spodziewaj się proszę, że wyczaruje cały gotowy system tylko dlatego że
ktoś nazwał mnie fantastą. Pokazałem jedynie że można i że nie
rozmawiamy tutaj o moich zwidach a o konkretnych możliwościach. I co
ważne "program" robi dokładnie to do czego został stworzony: kompiluje
pliki graficzne w locie i przeprowadza skład. Brak poskich znaków jest
trywialnym, acz czasochłonnym zagadnieniem. Naprawdę muszę udowadniać że
potrafie mieć polskie znaki w fop? Nie rozdrabniajmy się w rzeczy
nieistotne.
> A co do klikania -
> podczas 3 godzin kilkania mogê spokojnie z³o¿yæ ksi±¿kê w InDesignie lub
> Quarku. Potem korekta, poprawki i mo¿na daæ do druku. A Ty jak zamierzasz
> przeprowadzaæ korektê?
Nie muszę. Od tego jest żywy człowiek który przeprowadzi ją znacznie
dokładniej ode mnie. Jestem umysłem technicznym i daleko mi do wiedzy
językowej na takim poziomie. Tego zautomatyzować nie mogę. Całą resztę -
mam nadzieję - tak.
Stefan Nawrocki
> Stefan Nawrocki wrote:
> Postraszono mnie, że mogą pojawić się jakies dodatkowe elementy, zniknąć
> istniejące. Dopiero po paru postach wywnioskowałem (aczkolwiek dalej nie w
> prost) że dotyczy to niechlujnie przygotowanych pdfów a nie pdfów w ogóle.
> A więc jednak coś się dowiedziałem. Moim zdaniem mam teraz większą wiedzę
> niż przed.
Wydaje mi się, że nadal niewiele rozumiesz z tego, czemu coś znika, albo się
źle drukuje. I póki tego nie przećwiczysz - nic z tego nie będzie. To nie
jest kwestia "niechlujności" przygotowania pdf-a. Nie wiem, jak chcesz
ostatecznie tego pdf-a generować - i prawdę powiedziawszy - nie bardzo mnie
to interesuje. Albo napiszesz swój generator i wtedy - po wygenerowaniu iluś
tam pdf-ów i przeskoczeniu iluś tam niejasności wynikających z dokumentacji
tego formatu w końcu zacznie to jakoś chodzić (choć pewności nie będziesz
miał do końca, bo nie jesteś w stanie przetestować wszystkich istniejących
na rynku krojów, a także wszystkich ripów ze wszystkimi w nich możliwymi
ustawieniami).
Albo też - wykorzystasz gotowy generator (jak zrozumiałem - na to się
nastawiasz) - i wtedy jesteś po prostu uzależniony od niego.
>
> Niekoniecznie: jesli są opisywalne matematycznie to kto wie czy nie można
> ich wbudować. Obawiam się jednak że sztuka składu DTP jest w pewnym sensie
> nieopisywalna matematycznie. Dlatego muszę świadomie z tych elementów
> zrezygnować, bo sa one nieimplementowalne.
Naprawdę trzeba mieć do Ciebie cierpliwość. Wytłumaczono Ci przecież, że
"dobra książka", to taka, która w najlepszym stopniu zbliża się do
wielowiekowych zasad dobrego składu. To oczywiste, że jest w tym coś ze
sztuki i tego nie da się opisać, ale oczywiste jest też, że źle wygląda
sytuacja, kiedy np. nowy akapit zaczyna się na końcu kolumny i mieści się
tam tylko jeden wiersz z tego akapitu. Takich zasad jest wiele i one dają
się opisać. Jednak Ty napisałeś wprost, że Ciebie te zasady nie interesują,
bo Ty jest "programista" :-), a książki przez Ciebie generowane będą dla
"matmatyków", którzy podobnie jak Ty wolą skupić się na treści, a nie na
formie.
No więc, jeśli chcesz napisać system, który generuje pdf-y wsadowo na
podstawie dostarczonych plików nie przejmując się przy tym owymi
wielowiekowymi zasadami - to jest to zadanie trywialne. Doprawdy nie
rozumiem, czemu w tym układzie tracisz czas na pytania. Cały smaczek zadania
polegałby na inteligentym składzie, takim - który zoptymalizowałby układ
zdjęć, wielkość znaków, światła międzyznakowe, miedzywyrazowe,
międzywierszowe, itp. itd. po to, aby w wynikowym składzie liczba złamanych
zasad była jak najmniejsza.
Ale żeby to zrobić - trzeba po pierwsze poznać te zasady, po drugie - chcieć
je przestrzegać. Ty nie spełniasz obu warunków.
>
> Jesli znajdę matematyczną defninicję składu idealnego to nie widzę
> przeszkód aby takie narzędzie mogło za jakiś odległy czas powstać w tym co
> mam/będę miał. Jesli taka definicja nie istnieje, to nigdy nie powstanie.
Jak napisałem wyżej - bez uwzględnienia tych zasad - zadanie jest trywialne.
Stefan
Stefan Nawrocki
> a889 wrote:
> trywialnym, acz czasochłonnym zagadnieniem. Naprawdę muszę udowadniać że
> potrafie mieć polskie znaki w fop?
Dobrze byłoby, gdybyś jednak przećwiczył ten temat. Może wtedy przestałbyś
uważać, że to jest zagadnienie trywialne. Przede wszystkim - musisz się
zdecydować, czy chcesz pracować w ASCII czy w Unicode. ASCII jest
przestarzałe, jeśli Twój system ma być rozwojowy - zapomnij o ASCII i
stronach kodowych. Nie znam tego fop-a, więc nie wiem jak on pracuje, ale
przykład xml-a, który podałeś jest w iso-8859-2, czyli nie-unicodowy. W tej
chwili systemy nie obsługujące unicode w branży dtp przestają się liczyć.
A jak zdecydujesz się na unicode - to wtedy spróbuj wygenerować unicodowego
pdf-a (co np. objawi się tym, że będziesz miał znaki narodowe w zakładkach,
notatkach, itp.).
Jak już to zrobisz - to możemy podyskutować co dalej.
Stefan
Sebastian Bialy
> Albo te¿ - wykorzystasz gotowy generator (jak zrozumia³em - na to siê
> nastawiasz) - i wtedy jeste¶ po prostu uzale¿niony od niego.
Na szczęście czasami oprogramowanie ma otwarte źródła ... i mogę go
zmodyfikować. Choć to nie temat na tą grupę.
> Naprawdê trzeba mieæ do Ciebie cierpliwo¶æ. Wyt³umaczono Ci przecie¿, ¿e
> "dobra ksi±¿ka", to taka, która w najlepszym stopniu zbli¿a siê do
> wielowiekowych zasad dobrego sk³adu.
Wiem. Jednak najbardziej zastanawia mnie dlaczego wszyscy zachowują się
tak, jak gdybym chciał pisać od prawej do lewej, czcionką comic i z
akapitami w przerównych rozmiarach. Przecież nie zamierzam zrobić tego
niechlujnie. Wydawało mi się, że jakieś minimum poczucia estetyki i
stylu można było wobec mnie załozyć.
> To oczywiste, ¿e jest w tym co¶ ze
> sztuki i tego nie da siê opisaæ, ale oczywiste jest te¿, ¿e ¼le wygl±da
> sytuacja, kiedy np. nowy akapit zaczyna siê na koñcu kolumny i mie¶ci siê
> tam tylko jeden wiersz z tego akapitu.
To jest oczywiste. Na tyle, że mogę to zaimplementować. A wręcz będę
chciał to zaimplementować. Naprawdę ktoś tutaj przypuszczał, że zostawie
jakieś sieroty na stronach? To nie wygląda estetycznie. Tylo że na
szczeście jest automatyzowalne.
> Takich zasad jest wiele i one daj±
> siê opisaæ. Jednak Ty napisa³e¶ wprost, ¿e Ciebie te zasady nie interesuj±,
> bo Ty jest "programista" :-), a ksi±¿ki przez Ciebie generowane bêd± dla
> "matmatyków", którzy podobnie jak Ty wol± skupiæ siê na tre¶ci, a nie na
> formie.
Bzdura. Nie nie interesują, tylko są w większości na tyle trywialne w
implementacji, że nie ma co sobie zaprzątać głowy, we właściwym czasie
się je dorzuci. Priorytetem jest dla mnie zapanowanie na lini
pdf->drukarnia a nie drobnostki składu tekstu które są łatwe w zrobieniu
i zostawiam je na koniec. Nie odrzucam. Przemieszam na niższy priorytet.
To jest niepojęte, jak wiele osób uważa, że muszę starannie dobierać
czcionkę zamiast po prostu załozyc, że czcionki będą konfigurowalne. To
dla mnie oczywiste, że chyba dopiero teraz widze mój błąd. Powinienem
chyba jaśniej pisać: tak, estetyka i wygląd jak najbardziej. Tylko NA
BOGA nie od tego się zaczyna takie oprogramowanie. To są pierdoły
konfigurowalne z zewnatrz, pisane na koniec. Po co mam się nimi
zajmować, kiedy jądro systemu nie działa? I kiedy nie wiadomo czy dam
radę wygenerować właściwy pdf?
> No wiêc, je¶li chcesz napisaæ system, który generuje pdf-y wsadowo na
> podstawie dostarczonych plików nie przejmuj±c siê przy tym owymi
> wielowiekowymi zasadami - to jest to zadanie trywialne. Doprawdy nie
> rozumiem, czemu w tym uk³adzie tracisz czas na pytania. Ca³y smaczek zadania
> polega³by na inteligentym sk³adzie, takim - który zoptymalizowa³by uk³ad
> zdjêæ, wielko¶æ znaków, ¶wiat³a miêdzyznakowe, miedzywyrazowe,
> miêdzywierszowe, itp. itd. po to, aby w wynikowym sk³adzie liczba z³amanych
> zasad by³a jak najmniejsza.
Nie wszystkoz tej listy jest dla mnie priorytetowe a z częsci elementów
byc może zrezygunję. Może się okazac, że końcowy czytelnik nie zauważy
braku niektórych elementów a ja spędę wiele dni nad implementacją
jakiejś pierdoły.
Zrozum, nie zamierzam negować wypracowanych przez wieki zasad. Jednak
nie wszystkie zasady są niezbędne aby wyprodukować _dostatecznie_ dobrą
książkę. Dostatecznie. Nie idealną. Być może z niektórych zrezygnuje ze
względu na koszta implementacyjne. Ale częć będzie. Czy w ogóle ten
mechanimz powstanie - nie wiem. Może. Ale coś czuje, że próba dyskusji z
DTPowcami wymaga jednak pokazania próbki, bo inaczej nie dojdziemy do
porozumienia. A wykonanie próbki wymaga w pierwszej kolejności
znalezienia potencjalnych przeszkód. I o nie pytam. Przykro mi, ale bez
jasnego światła w tunelu nie będę się tym tematem zajmował i na dzień
dzisiejszy jedyne co mogę to przedstawić swoje założenia i pytać o
problemy. A to że się czasami nie rozumiemy to właśnie po to jest
dyskusja aby to wyjasnić.
Sebastian Bialy
> Dobrze by³oby, gdyby¶ jednak przeæwiczy³ ten temat. Mo¿e wtedy przesta³by¶
> uwa¿aæ, ¿e to jest zagadnienie trywialne. Przede wszystkim - musisz siê
> zdecydowaæ, czy chcesz pracowaæ w ASCII czy w Unicode. ASCII jest
> przestarza³e, je¶li Twój system ma byæ rozwojowy - zapomnij o ASCII i
> stronach kodowych.
Jedną z zalet bycia programistą jest fakt doskonałej znajomości tego
typu zagadnień. Wybacz, ale wiem o Unicode, ASCII i innych tego typu
problemach wystarczająco dużo, żeby trywialnych błedów nie popełniać.
> Nie znam tego fop-a, wiêc nie wiem jak on pracuje, ale
> przyk³ad xml-a, który poda³e¶ jest w iso-8859-2, czyli nie-unicodowy.
Unicodowość XMLa to można powiedzieć pewien fundament. To że w
dokumencie który podałem jest iso, to wyłącznie dla mojej wygody ze
względu na edytor którym się posługuje. Zapewniem cie, że jeśli wybiore
kodowanie UTF-8 to będę mógł pisać po chińsku, czesku i arabsku
jedncześnie. Bez żadnych zmian w transformacjach i programach. To jest
tak naturalne, że przyjmuje się za pewnik przy pracy z xml. Wszelkie
elementy systemu będą obrabiać unicode bo xml jest do tego przystosowany.
> A jak zdecydujesz siê na unicode - to wtedy spróbuj wygenerowaæ unicodowego
> pdf-a (co np. objawi siê tym, ¿e bêdziesz mia³ znaki narodowe w zak³adkach,
> notatkach, itp.).
_Zupełnie_ innym zagadnieniem jest to czy pdf się do tego nadaje.
Sprawdzę to, jednak nawet jeśli nie będę miał arabskiego to trudno - dam
radę.
Stefan Nawrocki
> Stefan Nawrocki wrote:
>> Albo te? - wykorzystasz gotowy generator (jak zrozumia3em - na to sie
>> nastawiasz) - i wtedy jeste? po prostu uzale?niony od niego.
>
> Na szczęście czasami oprogramowanie ma otwarte źródła ... i mogę go
> zmodyfikować. Choć to nie temat na tą grupę.
Ja wolę pisać od nowa, niż poprawać po kimś.
>
> Bzdura. Nie nie interesują, tylko są w większości na tyle trywialne w
> implementacji, że nie ma co sobie zaprzątać głowy, we właściwym czasie się
> je dorzuci.
Nie lubię takich słów jak "bzdura", ale sam się prosisz. To właśnie Ty
piszesz bzdury. Te trywialne wg Ciebie zasady, które Ty chcesz "dorzucić" we
właściwym czasie spędzają sen z oczu sztabom programistów. Ty po prostu
jeszcze nie poznałeś skali problemu, stąd Twoje wypowiedzi są bzdurne.
Pamiętaj, że jeśli nie chcesz mieć w ostatnim wierszu kolumny początku
akapitu i przerzucisz go na na początek następnej strony - to dostaniesz na
końcu strony zwyczajną "dziurę". Wiem - pisałeś, że Ciebie to nie rusza.
No - ale skoro chcesz zaimplementować tak "trywialną" zasadę - to musisz tę
"dziurę" wypełnić. I teraz trywialne pytanie - jak?
> Priorytetem jest dla mnie zapanowanie na lini pdf->drukarnia a nie
> drobnostki składu tekstu które są łatwe w zrobieniu i zostawiam je na
> koniec. Nie odrzucam. Przemieszam na niższy priorytet.
I tu chyba wreszcie sprawa się wyjaśniła. To co dla Ciebie jest jakimś
problemem i o co pytasz, jest w rzeczywistości trywialne, to co Ty uważasz
za trywialne - jest problemem, którego jeszcze nawet nie dotknąłeś.
Stefan
Stefan Nawrocki
> Stefan Nawrocki wrote:
> _Zupełnie_ innym zagadnieniem jest to czy pdf się do tego nadaje. Sprawdzę
> to, jednak nawet jeśli nie będę miał arabskiego to trudno - dam radę.
Że się nadaje - to pewne - ja napisałem taki generator, który generuje pdf-a
unicodowego. Ale czy to jest zadanie trywialne - to sprawdź sam :-).
Stefan
wyzimir
> [...] i cala reszta watku ;)
>
> nie przejmuj sie ;)
>
> jezeli to ma byc publikacja techniczna i cz/b i odpowiada Ci jej wyglad wg. Twojego projektu - to rob tak jak opisujesz ;)
>
> zrob PDF'a i wydrukuj go na laserowce - jezeli wyjdzie wizualnie OK - to oddaj do naswietlarni :)
> tylko pamietaj, zeby wszedzie byl jeden kolor - czarny z odcieniami :)
Jak czytam powyższe wiadomości od DTP-owców to mi ciarki po plecach
chodzą z góry na dół. Koledzy DTP-owcy chcą powiedzieć, że prepress to
czarna magia, a może całość opiera się na czynniku losowym.
Przecież programy DTP też korzystają z tej automatyki, o której pisze
Sebastian. Przecież wstawiamy tabele z baz danych, raz przygotowany
dokument/layout może zmieniać wersję językową, dzięki wlaniu w niego
odpowiedniego dokumentu xml, generuje się tysiące spersonalizowanych
dokumentów z baz danych, itp.
Praca DTP-owca nie polega tylko na składzie - a skład nie polega tylko
na "przeklejeniu tekstu z Worda". Po "przeklejeniu" dba o czytelność i
estetykę dokumentu. Tego maszyny jeszcze nie potrafią.
Sebastian przekształcając automatycznie xml na pdf-a ostyluje go,
wstawi grafikę (zapewne w odpowiednim formacie i w rozdzielczości),
dokument będzie spójny, da się go czytać, ale niekoniecznie czytelny i
estetyczny. Chociaż może wyjść mu całkiem zgrabnie (chciałbym zobaczyć
efekt).
Jeśli nie wie o różnych problemach z RIP-owaniem to z pewnością go
ominą, nie założy niepotrzebnych overprintów, nie będzie trapingu,
zapewne skorzysta z profesjonalnego fontu (przecież są dostępne za
darmo, np. z Adobe Readerem). Jeśli to co zobaczy na ekranie i to co
wydrukuje na drukarce (najlepiej postscriptowej) zadowoli go, to może
śmiało dawać plik do drukarni.
Jeśli w dokumencie nie będzie grafiki na spad, to nie musi martwić się
o spady, marki cięcia, pasowania, gięcia, itp.
Jeśli będą drobne błędy to podczas prepresu można je często poprawić,
dodać potrzebne informacje drukarskie, itp.
Duża część pracy DTP-owca to dbanie o estetykę dokumentu.
Reszta to znajomość przygotowania materiałów pod konkretne wymagania
techniczne przy konkretnej produkcji. Bo w WYSWIG nie zawsze pokaże
overprinty, laik nie będzie wiedział o co chodzi z kolorami spotowymi,
z po co jakiś traping, liniatura, UCR, GCR, ICC, dlaczego drobny tekst
drukujemy 100%K.
DTP-owcy denerwują się gdy ktoś kto się na tym nie zna postanawia sam
przygotować dokument, bo potem jego przerobienie może często zająć
więcej niż skład, albo będą nieustannie lękani złymi plikami lub
pytaniami o podstawowe rzeczy.
igoR szczurka
> Sebastian przekształcając automatycznie xml na pdf-a ostyluje go,
> wstawi grafikę (zapewne w odpowiednim formacie i w rozdzielczości),
> dokument będzie spójny, da się go czytać, ale niekoniecznie czytelny i
> estetyczny. Chociaż może wyjść mu całkiem zgrabnie (chciałbym zobaczyć
> efekt).
Daj spokój. Widziałeś jego "idealny" dokument?
On cały czas myśli że tu wszystkim się o styl i estetykę rozchodzi...
Tymczasem: pal licho estetykę - puść preflight na tym "bezbłędnym" czymsiu.
Włosy się jeżą...
A on nadal swoje. Krzyżyk na drogę; wie lepiej,
--
C
igoR szczurka |'_> FAQ grupy pl.comp.dtp
@ gmail com / | http://dtp.art.pl
| \\
---=============\___DD GG:5239818 / Skype:igor_sz
Sebastian Bialy
> Pamiêtaj, ¿e je¶li nie chcesz mieæ w ostatnim wierszu kolumny pocz±tku
> akapitu i przerzucisz go na na pocz±tek nastêpnej strony - to dostaniesz na
> koñcu strony zwyczajn± "dziurê". Wiem - pisa³e¶, ¿e Ciebie to nie rusza.
> No - ale skoro chcesz zaimplementowaæ tak "trywialn±" zasadê - to musisz tê
> "dziurê" wype³niæ. I teraz trywialne pytanie - jak?
Pustą linią - pierwsze podejście. Czymkolwiek, co da mi xml:fo orphans.
Sianem.
Nie wiem. Nie jestem w stanie powiedzieć jakimi metodami osiągnę
zamierzony cel usunięcia lini i czym wypełnie (i czy w ogóle wypełnie!).
Żądasz ode mnie rozwiązania wszystkich problemów już teraz, kiedy ja
chcę na razie rozeznać się w terenie i znaleźc potencjalne przeszkody
dużej skali typu "czy pdf to dobry wybór". Przeciez ja jeszcze nie
zasiadłem do dłubania. Kiedy uda mi się ocenić możliwość dogadania się z
drukarną w następnej kolejności zastanowie się nad możliwością
zautomatyzowania składu tekstu.
Gdybym napisał "robie własnie system DTP" to twoje uwagi miały by sens.
Ale ja na razie ROZWAŻAM taką możliwość. I w pierwszej kolejności muszę
poznać najmniej dla mnie znany element tego procesu.
Uszegółowianie do poziomu "co zrobić z linią" nie jest aktualnym etapem
projektowania. Być może okaże się na tyle skomplikowane, że porzuce
projekt (choć wątpie).
Sebastian Bialy
> On cały czas myśli że tu wszystkim się o styl i estetykę rozchodzi...
> Tymczasem: pal licho estetykę - puść preflight na tym "bezbłędnym" czymsiu.
> Włosy się jeżą...
> A on nadal swoje. Krzyżyk na drogę; wie lepiej,
Nie wiem czy potraficz czytać ze zrozumieniem mój post, ale jesli
przeczytasz go jeszcze raz być może znajdziesz tam wzmiankę, że to coś
powstało w 3 godziny i jest dowodem na to że można. Można byle jak ale
można (ponieważ zarzucono mi obracanie się w sferze SF). Jesli natomiast
zamierzasz mnie oceniać po tym dokumencie to pozostaje mi po prostu
głośno się roześmiać, bo oceniasz zawartość książki po zakładce z
wydrukowaną reklamą.
Nie mogę stać bezczynnie kiedy ktoś obrzuca mnie błotem wmawiając mi że
zmyślam. Przygotowałem więc coś co tą tezę neguje. Marnie, ale jednak.
Proszę, abyć nie oceniał tego dokumentu pod kątem DTP bo on nie powstał
w tym celu. Po prostu. Powstałw celu zanegowania tezy o SF.
I gdzie napisałem że to _coś_ jest bezbłędne ?
Stefan Nawrocki
> Stefan Nawrocki wrote:
>
> Nie wiem. Nie jestem w stanie powiedzieć jakimi metodami osiągnę
> zamierzony cel usunięcia lini i czym wypełnie (i czy w ogóle wypełnie!).
> Żądasz ode mnie rozwiązania wszystkich problemów już teraz, kiedy ja
Żartujesz? Ja niczego od Ciebie nie żądam. Pytałeś o problemy. No to
dostałeś odpowiedzi, że nie generowanie pdf-a jest problemem, ale właśnie
owe "dziury". Nie przyjąłeś tej wiedzy. Stwierdziłeś, że estetyka Cię nie
interesuje. Więc po co pytasz dalej? Generowanie pdf-a, to problem czysto
techniczny, choć nie trywialny. Na dodatek korzystasz z zewnętrznego
generatora, wiec w czym problem? Wygeneruj tego pdf-a i zanieś do drukarni.
Jeśli będzie ok - to dobrze. Jeśli będzie źle - to i tak nie masz wpływu na
szczegóły generowania pliku (chyba, że wejdziesz w źródła tego generatora).
Nie rozumiem więc w czym problem?
Stefan
a889
> Proszę, abyć nie oceniał tego dokumentu pod kątem DTP bo on nie powstał w
> tym celu. Po prostu. Powstałw celu zanegowania tezy o SF.
>
> I gdzie napisałem że to _coś_ jest bezbłędne ?
Ale jeśli to coś nie jest bezbłędne, to jego przydatność jest żadna. Nie
rozumiesz tego?
DTP można uczyć się na własnych błędach, ale to nauka bardzo kosztowna.
Taniej wyjdzie zapłacić DTP-owcowi za skład tej książki, ewentualnie kupić
jakiś program do składu, niż z powodu jakiegoś "drobnego" błędu wysyłać
nakład na przemiał.
Stefan Nawrocki
Użytkownik "Sebastian Bialy" <he...@poczta.onet.pl> napisał w wiadomości
news:eump8l$oq8$1...@nemesis.news.tpi.pl...
> I gdzie napisałem że to _coś_ jest bezbłędne ?
No to zrób - żeby było bezbłędne. Wiesz - "prawie" - robi różnicę.
Stefan
igoR szczurka
> Nie wiem czy potraficz czytać ze zrozumieniem mój post, ale jesli
> przeczytasz go jeszcze raz być może znajdziesz tam wzmiankę, że to coś
> powstało w 3 godziny i jest dowodem na to że można. Można byle jak ale
> można (ponieważ zarzucono mi obracanie się w sferze SF).
"SF" odnosiło się chyba właśnie do DTP; nikt nie zarzucił Ci że się nie da
w ogóle. Uświadamiano Ci jedynie jak bardzo można spieprzyć dokument z
punktu widzenia technologii przygotowania do druku. Ty w 3h
wspaniałomyślnie udowodniłeś to co wszyscy wiedzieli: że tak, MOŻNA
spieprzyć ;>
Gratuluję. Nie chce mi się więcej pisać, bo IMAO nie ma o czym.
wyzimir
> >> przeciętnej laserówce.
Jeśli laserówka jest postscriptowa, to dokument powinien wyglądać
podobnie (kolory będą zapewne inne niż w wydruku z maszyny, a RIP
drukarki może nie obsługiwać w pełni postscriptu).
> >> W jaki sposób może się z nienacka coś pojawić?
> > Np. coś jest ukryte, ale rip to widzi.
W Adobe Readerze nie zobaczysz na przykład tła poddrykowanego pod
obiektami z overprintem, nie zobaczysz kolorów specjalnych, i wiele
więcej.
Ale w twoim "automatycznym składzie" zapewne nie będziesz miał
potrzeby używania różnych funkcji, więc w ten sposób nic nie
zepsujesz.
> Jak może widzieć coś, czego ja na monitorze nie widzę? Jesli jest tak,
> że pdf nie daje tego samego obrazu co maszyna drukarska to to jest
> jakieś bagno mówiąc obrazowo i faktycznie zaczynam się poważnie
> zastanawiać czy to ma sens. Nie przypuszczałem że napotkam na tak
> debilny problem. Zawsze mi się wydawało że drukarnia robi metodą WYSIWYG
> zakładając margines na błedy technologiczne. A tu się okazuje że
> problemy rozwiązane 20 lat temu w informatyce nadal straszą w
> drukarniach. Paranoja.
Profesjonalne oprogramowanie pokaże ci to (zasymuluje odpowiedni
widok) czego nie zobaczysz w niedetepowskiej przeglądarce pedefów.
> > Nie albo. Musi być CMYK. Jak zrobisz w RGB to Cię drukarnia wyśle na
> > drzewo.
Ja poprosiłbym o poprawkę, jeśli faktycznie to wpływało by znacząco na
wartość całej produkcji, lub sam bym poprawił (jeśli dało by się to w
miarę łatwo i chciałbyś zapłacić).
> >> Zwracam uwagę że dokument PDF będzie _perfekcyjny_ bo stworzony
> >> automatycznie.
> > ROTFL
Zapewne nie będzie zawierał wielu błędów, które generują rozbuchane
programy detepowskie. O ile biblioteka/program generuje kod zgodnie z
standardem.
> Nie, musiś poćwiczyć telepatię. Wszystkie są w:
>
> a) asymptote
> b) graphwiz
> c) svg
to nie są formaty dtp-woskie, ale chyba nie ma problemów, żeby końcowy
plik był czytelny dla RIP-a.
[...]
> A w czym jest lepszy zakładając że mam do dyspozycji np. konsolę unixa w
> której chciałbym poleceniem wykonać konwersję xml->pdf ?
Jeśli wydasz w UNIX-ie takie polecenie to po prostu wygenerujesz pdf-
a, składem nazwiemy raczej stworzenie potrzebnych arkuszy stylów.
a889
> Kiedy uda mi się ocenić możliwość dogadania się z drukarną w następnej
> kolejności zastanowie się nad możliwością zautomatyzowania składu tekstu.
Bez urazy, ale każda drukarnia słysząc taki bełkot, nie będzie chciała w
ogóle gadać, nie mówiąc już o podjęciu się druku. Ja bym się nie podjął, bo
czasem działam na zasadzie - upierdliwego klienta lepiej sobie odpuścić, niż
mieć potem z nim problemy.
Sebastian Bialy
> Taniej wyjdzie zap³aciæ DTP-owcowi za sk³ad tej ksi±¿ki, ewentualnie kupiæ
> jaki¶ program do sk³adu, ni¿ z powodu jakiego¶ "drobnego" b³êdu wysy³aæ
> nak³ad na przemia³.
a) gdzie znajdę DTPowca potrafiącego kompilować obrazki w asymptote i
rozumiejącego pojęcie repozytorium wersji SVN?
b) gdzie znajdę program do składu potrafiący kompilować obrazki w
asymptote i używającego repozytorium wersji SVN?
Bo chyba nie chcesz mi powiedzieć, że jedynym rozwiązaniem jest
zrezygnować z nowoczesnych narzędzi i wszystko robić w mapach bitowych.
To by był naprawde krok w stecz.
Widzisz, jak się tak upieram przy _moim_ składzie ponieważ mam pewne
wyobrażenie o tym co potrzebuje, a jak widać na tej grupie jest ono nie
do pogodzenia z większością profesjonalistów. I boje się, że efektem
końcowym dokumentu będzie zarąbiste dzielenie wyrazów i przestrzenie
akapitowe oraz full-wypas spady jednak totalnie spieprzona logika i
treść obrazków i tekstu.
A w ogóle: przecież to mój czas i pieniądze. Dlaczego miałbym nie
spróbować i urodzi się z tego przydatne narzedzie?
Sebastian Bialy
>>Kiedy uda mi siê oceniæ mo¿liwo¶æ dogadania siê z drukarn± w nastêpnej
>>kolejno¶ci zastanowie siê nad mo¿liwo¶ci± zautomatyzowania sk³adu tekstu.
> Bez urazy, ale ka¿da drukarnia s³ysz±c taki be³kot, nie bêdzie chcia³a w
> ogóle gadaæ, nie mówi±c ju¿ o podjêciu siê druku. Ja bym siê nie podj±³, bo
> czasem dzia³am na zasadzie - upierdliwego klienta lepiej sobie odpu¶ciæ, ni¿
> mieæ potem z nim problemy.
Rozumiem że jeśli przyjdę do Ciebie z gotowym PDFem i powiem że ma takie
a takie cechy, fonty, rozmiary to wyrzucisz mnie za drzwi za bełkot?
Myślisz że będę tłumaczył mechanikowi od maszyny zawiłości systemu
xml->pdf? Żartujesz chyba. Jeśli będę wiedział wystarczająco dużo jak
zrobić prawidowy pdf to go po prostu oddam i niech sami ocenią.
Sebastian Bialy
> No to zrób - ¿eby by³o bezb³êdne. Wiesz - "prawie" - robi ró¿nicê.
Żeby co i komu i za ile udowodnić?
Marek Włodarz
Sebastian Bialy napisał(a):
[ciach]
Pojawiłeś się tu i zadałeś pytanie. Kilka pytań. Brzmiały
interesująco, więc ci odpowiedziano - ja też.
Problem w tym, że nie słuchasz odpowiedzi.
A teraz bądź tak miły i wróć, jak będziesz miał _coś_ do powiedzenia.
Np. pokażesz, co zrobiłeś. Coś godnego poświęcenia temu 5 minut.
Przynajmniej tyle. Na razie - oprócz wielu pustych słów - nie
pokazałeś nic.
Spytasz może, co my możemy pokazać? Ano, zawartość każdej księgarni.
Trochę tego jest.
Bo na razie wygląda to tak, że wiesz lepiej. No to sobie wiedz lepiej.
zapłać za ten druk. Pokaż książkę. Jeśli będzie dobra, będę pierwszy,
który cię pochwali.
Tylko nie wiem czemu, mam dziwne przekonanie, że nigdy tego nie
zobaczę...
Pozdrawiam,
Marek W.
--
FAQ grupy pl.comp.dtp: http://dtp.art.pl/
Lista mirrorów: http://emide.neostrada.pl
"Nie pracuje dobrze ten, kto z zamiarem wykonania łopaty buduje rakietę."
Stanisław Lem.
Sebastian Bialy
> "SF" odnosiło się chyba właśnie do DTP; nikt nie zarzucił Ci że się nie da
> w ogóle.
cytat:
Pawel Nawrocki wrote:
> [...] Ale skoro to, co tak namiętnie i żarliwie opisywałeś, jest
tylko i wyłącznie teorią niepopartą żadnym konkretnym przykładem [...]
Klamstwo. Nie jest tylko i wyłącznie teorią. Jest od dawna znaną
praktyką (choć z nieco innymi założeniami) pod nazwą np. DocBook.
> Ty w 3h
> wspaniałomyślnie udowodniłeś to co wszyscy wiedzieli: że tak, MOŻNA
> spieprzyć ;>
Nie. Udowodniłem że to co dla wielu jest abstrakcyjną potrzebą nie dość
że jest wykonalne, to jeszcze jest wystarczająco łatwe aby dało się
dostać coś z niczego w 3 godziny.
Mamy kompletnie inne priotytety. Dla DTPowców najwidoczniej
wygenerowanie pdfa w tak którkim czasie za pomocą darmowych narzędzi
jest mniej imponujące niż wyklikanie tego samego w quarku. Dla mnie
jednak jest bo otwiera mi drogę do automatyzacji dokumentu.
Automatyzacji która jest podstawą całości pomysłu. I która nie jest ani
troche tematem wątku a jednocześnie stała się podstawowym przedmiotem
dyskusji. Zamiast rozmawiać o ewentualnych problemach pdf->drukarnia to
nagle wszyscy (statystycznie) dźgają mnie widłami, walą pałką w łeb bo
ośmieliłem się użyć innego narzędzia niż ich jedynie słuszne i
OCZYWIŚĆIE spieprzyłem, bo przeciez w 3 godziny powinienem na spokojnie
uzyskać jakość quarka "abo i lepiej". Smutne, ale na szczeście między
tymi uderzeniami czasami coś ciekawego jeszcze wyłowie z dyskusji. Mimo
wszystko dzięki nawet za to pałowanie, zawsze to jakieś doświadczenie.
> Gratuluję. Nie chce mi się więcej pisać, bo IMAO nie ma o czym.
Dokładnie, szczególnie jak tak się stawia sprawę. Dziękuje jednak za
krytyczne uwagi i pozdrawiam serdecznie.
Sebastian Bialy
> ¯artujesz? Ja niczego od Ciebie nie ¿±dam. Pyta³e¶ o problemy. No to
> dosta³e¶ odpowiedzi, ¿e nie generowanie pdf-a jest problemem, ale w³a¶nie
> owe "dziury". Nie przyj±³e¶ tej wiedzy. Stwierdzi³e¶, ¿e estetyka Ciê nie
> interesuje. Wiêc po co pytasz dalej?
Chcę nieśmiao zauważyc, że to nie ja zapytałem pierwszy o estetykę. Ja
pytałem tylko o ewentualne problemy techniczne na styku pdf->drukarnia.
Mnie na dzień dzisiejszy nie interesuje skład techniczny w stopniu tak
szczegółowym. Kluczowa sprawa to drukarnia.
> Generowanie pdf-a, to problem czysto
> techniczny, choæ nie trywialny. Na dodatek korzystasz z zewnêtrznego
> generatora, wiec w czym problem? Wygeneruj tego pdf-a i zanie¶ do drukarni.
Jak to napisłem to od razu wyskoczyli ludzie na grupie twierdzący
usilnie że maszyna drukarska posiada generator losowych kresek i
nieaktualne sterowniki. I lepiej żebym tego nie robił. Może faktycznie
lepiej o nic nie pytać tylko zanieść.
> Je¶li bêdzie ok - to dobrze. Je¶li bêdzie ¼le - to i tak nie masz wp³ywu na
> szczegó³y generowania pliku (chyba, ¿e wejdziesz w ¼ród³a tego generatora).
> Nie rozumiem wiêc w czym problem?
Problem w tym, że dostaje masę niejasnych odpowiedzi, często
sprzecznych. Przedstawiające wizje ręcznego składu jako wielką
katastrofę od której uratować mnie może nawrócenie się na ciemną stronę
mocy i wynajęcie mistrza. W dodatku dyskusja toczy się w całkiem innym
kierunku. Czego kompletnie nie rozumiem bo jest dość oczywiste że
DTPowieć nie rozumie moich potrzeb stosowania xml a ja nie zrozumiem
potrzeby zastanawiania się nad pustą bądź nie ostatnią linią. Teraz
żałuje że dałem się wcisnąć w tą jałową dyskusję o generowaniu samego
pdf. To się mija z celem bo to rozmowa z betonem i to w obydwie strony
równie twardym bo ja też nie popuszczam.
wyzimir
[...]
> Bo chyba nie chcesz mi powiedzieć, że jedynym rozwiązaniem jest
> zrezygnować z nowoczesnych narzędzi i wszystko robić w mapach bitowych.
> To by był naprawde krok w stecz.
Może powinieneś pomyśleć nad Scribusem (opensourcowy poogram DTP) i
spróbować napisać do niego odpowiednie wtyczki? W ten sposób mógłbyś
poprawić błędy, których "nie zauważył" twój program.
> Widzisz, jak się tak upieram przy _moim_ składzie ponieważ mam pewne
> wyobrażenie o tym co potrzebuje, a jak widać na tej grupie jest ono nie
> do pogodzenia z większością profesjonalistów. I boje się, że efektem
> końcowym dokumentu będzie zarąbiste dzielenie wyrazów i przestrzenie
> akapitowe oraz full-wypas spady jednak totalnie spieprzona logika i
> treść obrazków i tekstu.
Książka, to technicznie prosty dokument, jeśli wygenerujesz go
automatycznie, to powinien być on poprawny, a drukarnia nie powinna
mieć problemów z drukiem (jestem prawie pewien, że nie będzie
kłopotów).
Do kolegów DTP-owców. W ten sam sposób, w który SB chce złożyć swoją
książkę, są "składane" strony internetowe, a je przecież daje się
czytać. Co prawda od papieru wymagamy czego innego niż od ekranu, ale
oba media są równie czytelne. Po prostu jego książka nie będzie
arcydziełem typografii ;-)
Jeśli Sebastian przyniesie takie a nie inne materiały, to nie widzę
powodów dlaczego drukarnia ma mu tego nie wydrukować (przecież
zapłaci).
Sebastian Bialy
> A teraz bądź tak miły i wróć, jak będziesz miał _coś_ do powiedzenia.
> Np. pokażesz, co zrobiłeś. Coś godnego poświęcenia temu 5 minut.
> Przynajmniej tyle. Na razie - oprócz wielu pustych słów - nie
> pokazałeś nic.
Nie przesadzaj. Coś pokazałem. Coś co jest z mojej strony niezwykle
ciekawe, choć ze strony DTPowca raczej zabawne. Z czego sobie zdaje sprawę.
> Spytasz może, co my możemy pokazać? Ano, zawartość każdej księgarni.
> Trochę tego jest.
Uwierz mi, że wiele książek przeczytałem w życiu. I wiele z nich ocenił
bym bardzo słabo jeśli chodzi o ogólnie pojęta estetykę. Dlatego nie
uważam że będę bardzo odstawał od normy. Naprawdę stać mnie na to a może
i na więcej.
> Tylko nie wiem czemu, mam dziwne przekonanie, że nigdy tego nie
> zobaczę...
Bo być może się na to nie zdecyduję. Proste.
Mimo wszystko dziękuje serdecznie za rady i wskazówki. Dają mi wiele do
przemyślenia i weryfikacji moich pomysłów.
Stefan Nawrocki
> Żeby co i komu i za ile udowodnić?
Co? Że panujesz nad materią, a nie materia nad Tobą.
Komu? A komu pokazałeś wcześniej tego niedorobionego pdf-a?
Za ile? Lepiej zapytaj ile masz dopłacić za ogłądanie tego :-).
Co Ty nam właściwie pokazałeś - że mając xml-a potrafisz za pomocą
zewnętrznych programów wygenerować pdf-a?
I co? Myślisz, że odkryłeś Amerykę?
Stefan