wiget: SPECS gimp-print.spec,1.4,1.5
Tomasz Kłoczko
kloczek w rudy.mif.pg.gda.pl
Pią, 8 Lut 2002, 15:48:44 CET
On Fri, 8 Feb 2002, wrobell wrote:
> On Fri, Feb 08, 2002 at 02:45:08PM +0100, Tomasz Kłoczko wrote:
> > On Fri, 8 Feb 2002, wrobell wrote:
> > [..]
> > > Nie przyglądałem się tym pakietom, ale z powyższych
> > > punktów wynika, że pakiet może _jednocześnie_ zawierać dokumentację
> > > w następujących formatach (ew. rozbitych na pakiety jeśli coś dużo
> > > miejsca zajmuje):
> > > - info, PDF, txt
> > > lub
> > > - html, PDF, txt
> > > lub
> > > - info, PS, txt
> > > itp, itd.
> > >
> > > W ten sposób, oprócz czystego txt, mamy zawsze format hipertekstowy,
> > > a także format gotowy do wydruku.
> >
> > No i pisze juz któryś raz że zmiast dostarczać to wszystko lepiej jest
> > dostaczyć źródło i peogram od generowania tych formatów wynikowych.
>
> Zauważ, że nie piszę o dystrybuowaniu man-ów w postaci PS. Dlaczego?
> Ano, ponieważ:
>
> man -t groff | lpr
Teraz zauważ ie osób to wykonuje.
> Natomiast jak będzie z info?
> info2ps glibc | lpr
> ? Da się?
Nie da sie bo jest texi2ps.
> html2ps? Zapomnij, nie ma tak dobrego konwertera. Jeśli się mylę,
> to daj znać.
Czyżbyś chciał powiedzieć że mamy to dostarczać także ?
Jak na razie nie napisałem niczego co by dotykało powyśzego kierunku
renderingu. html traktuje jako postać wynikową. Z xml da sie ładnie
wygenerować zaróno ps jak i html wiec nei rozumiem po co drązysz kolejne
ogałzienie mozliwego mniej czy bardziej sensowanego konwertowanai czegoś
takeigo. Po za tym przypomnę ze cąłkiem niezy wynik ps z html daje ..
szkapa czy mozilla.
> Zauważ, że wymieniane przeze mnie 6 w/w punktów uwzględnia
> obecnie istniejące konwertery. Np.: upieram się przy większym
> priorytecie dla DVI niż dla PS ponieważ:
O ile jest tylko albo dvi albo ps zgoda.
> 1. istnieje do DVI pod konsolę lepsza przeglądarka (tmview)
> niż dla PS
> 2. łatwo i przy zachowaniu odpowiedniej jakości (sic!)
> skonwertować DVI na PS:
>
> dvi2ps -o - plik.dvi | lpr
>
> > Dostarczać źródło jest sens o ile można nic innego nie dokładać czyli o
> > ile będzie się miało przeglądarkę do xml i odpwiednie konwertery. W
> [...]
> Problem polega na tym, że obecnie nie ma i nie zanosi się w najbliższym
> czasie (do roku) na to, że będą odpowiednie konwertery xml->pdf istniały.
To do nędzy jak to sie robi w takim razie i dlaczego konwersja z
pośrednictwem TeXa Ci nie pasuje ?
> Dowolny xml możesz konwertować do xsl:fo,
Ale wcale nie musże używać do tego wprost xsl. Mogę wygenerować ot w kilku
krkach.
> jeśli istnieje odpowiedni
> styl. Powiedzmy, że nie jest to problemem (jakość styli dla np.: DocBook-a
> XML-owego jeszcze nie jest odpowiednia, zobaczymy jak będzie z texi).
> Teraz chciałbym takiego xsl:fo:
>
> fo2ps | lpr
>
> Jest takie narzędzie, które daje odpowiednią jakość? Istnieją
> dwaj kandydaci: passivetex (TeX) i fop (Java). Obydwa projekty mają
> jeszcze conajmniej rok przed sobą jeśli nie dłużej (a passivetex
> coś chyba nie jest zbytnio rozwijany ostatnio).
Istnienie tego tylko przyśpiesza uzyskanie porżadanego formatu wynikowego
czy są jakeiś inne róznice ?
Tak czy inaczej powyższe ma sie nijak do dyyskucji na temat texi/info bo
traktuje o zupełni czymś innym.
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*
Więcej informacji o liście dyskusyjnej pld-devel-pl