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