Bug 192912

------- Additional Comments From jkeating  2006-06-12 10:35 EST -------
Now needs libtool and doxygen build requirements.

E: paps zero-length /usr/share/doc/paps-0.6.6/NEWS

------- Additional Comments From jkeating  2006-06-11 11:04 EST -------
NEEDSWORK
- Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built.
- BuildRequires: automake
- %makeinstall no longer acceptable according to guidelines.  Try "make install
DESTDIR=$RPM_BUILD_ROOT" instead.


Question
- Any way to make this so that we don't have to use autotools to build it?  This
is fragile and ugly.

------- Additional Comments From tagoh  2006-06-11 21:27 EST -------
(In reply to comment #3)
> NEEDSWORK
> - Brew doesn't support %{?dist} tag anymore, so this will not evaluate when built.

Yes, I was aware of this and was about to modify it before next build.

> - BuildRequires: automake
> - %makeinstall no longer acceptable according to guidelines.  Try "make install
> DESTDIR=$RPM_BUILD_ROOT" instead.

Ok, I'll update.

> Question
> - Any way to make this so that we don't have to use autotools to build it?  This
> is fragile and ugly.

Hm, I could contain the chunks of Makefile.in in a patch though, it may causes
an issue that is hard to maintain it.

------- Additional Comments From jkeating  2006-06-11 21:38 EST -------

> > Question
> > - Any way to make this so that we don't have to use autotools to build it?  This
> > is fragile and ugly.
> 
> Hm, I could contain the chunks of Makefile.in in a patch though, it may causes
> an issue that is hard to maintain it.

Its really your choice.  Which ever method you feel more comfortable supporting.

------- Additional Comments From tagoh  2006-06-11 23:13 EST -------
Ok, updated in Extras CVS, except dist tag.

------- Additional Comments From besfahbo  2006-06-11 23:49 EST -------
Just a note that most (if not all) of the code in libpaps.c is essentially
deprecated now that cairo has PS/PDF backends being enabled for FC6.  It should
be a matter of a weekend's work to get someone write a paps-like a2ps
replacement using pangocairo.

This can be fixed later of course, and the upstream author already knows about
this and may in fact do it himself.  My other concern with paps as it stands now
is its command line interface that we have to keep if we push it into Core. 
Instead of --fontscale and --family for example, it should have a single --font
that takes a Pango font description.

Such a tool can be included in Pango upstream in fact.

If there's no strong reason for having paps or a similar tool in Core for FC6, I
suggest postponing this and working on the replacement tool.

------- Additional Comments From tagoh  2006-06-12 01:03 EST -------
(In reply to comment #7)
> Just a note that most (if not all) of the code in libpaps.c is essentially
> deprecated now that cairo has PS/PDF backends being enabled for FC6.  It should
> be a matter of a weekend's work to get someone write a paps-like a2ps
> replacement using pangocairo.
> 
> This can be fixed later of course, and the upstream author already knows about
> this and may in fact do it himself.

Yes, upstream is aware of that.

>                                      My other concern with paps as it stands now
> is its command line interface that we have to keep if we push it into Core. 
> Instead of --fontscale and --family for example, it should have a single --font
> that takes a Pango font description.

It sounds good. let me push it to upstream then.

> Such a tool can be included in Pango upstream in fact.

Not as an example? it would be nice if it will continues to be maintained.

> If there's no strong reason for having paps or a similar tool in Core for FC6, I
> suggest postponing this and working on the replacement tool.

We are focusing to improve the CIJK handling of the text printing and paps was a
better candidate at that time - this was being developed since PS/PDF backend
for cairo was experimental or before that, which wasn't relied on - We have
decided to work on paps because it may be close to become successful at RHEL5
timeframe so that the improvement of CIJK text printing is our goal for RHEL5.
plus, we have no enough time to make an another replacement from scratch so that
FC6t1 will be coming soon.

------- Additional Comments From besfahbo  2006-06-12 01:46 EST -------
> >                                My other concern with paps as it stands now
> > is its command line interface that we have to keep if we push it into Core. 
> > Instead of --fontscale and --family for example, it should have a single --font
> > that takes a Pango font description.
> 
> It sounds good. let me push it to upstream then.

Ok good.  While communicating with upstream, suggest that he ports paps to
pangocairo over the weekend, and we may actually have it next week :-).


> > Such a tool can be included in Pango upstream in fact.
> 
> Not as an example? it would be nice if it will continues to be maintained.

Yeah, I'm already trying to push the pango-view tool as a stable maintained tool
(instead of an example), and it's been packaged in pango-devel for a while now.
 I also have wanted to add PS/PDF output support to it for a while.

Main thing that needs to be done before pango-view can be used like paps is to
make it break text into paragraphs before laying out (for performance reasons.)
 I'm actually not sure that paps does that.  But anyway, I probably will get to
doing that sooner or later, but can't make any promise at this point.


> > If there's no strong reason for having paps or a similar tool in Core for FC6, I
> > suggest postponing this and working on the replacement tool.
> 
> We are focusing to improve the CIJK handling of the text printing and paps was a
> better candidate at that time - this was being developed since PS/PDF backend
> for cairo was experimental or before that, which wasn't relied on - We have
> decided to work on paps because it may be close to become successful at RHEL5
> timeframe so that the improvement of CIJK text printing is our goal for RHEL5.
> plus, we have no enough time to make an another replacement from scratch so that
> FC6t1 will be coming soon.

Ok, what about having a simple shell script called u2ps shipped and advertised
in Core with a documented command line interface, and make it call paps as the
implementation for now, but leave it open to switch to pango-view later on... 
The interface should be quite simple, a cat-like tool with the following options:

  --landscape
  --portrait (Default)
  --font
  (--font-size, --font-family, ...?)
  --margin
  --margin-left
  --margin-right
  --margin-top
  --margin-bottom
  --header=[TEXT]
  --footer=[TEXT]

That should be enough for now, and (except for footer?) paps supports the rest
already, with different namings possibly.

Another thing that should work in u2ps but is not currently working in paps is
setting default paper size based on LC_PAPER.  We can make the wrapper figure
out the paper and pass it to paps for now, and use it to set page size later
with pango-view.

------- Additional Comments From tagoh  2006-06-12 02:33 EST -------
(In reply to comment #9)
> Main thing that needs to be done before pango-view can be used like paps is to
> make it break text into paragraphs before laying out (for performance reasons.)
>  I'm actually not sure that paps does that.  But anyway, I probably will get to
> doing that sooner or later, but can't make any promise at this point.

I'm not sure that I understood what you mean though, paps splits up each lines
into the paragraphs.

> Ok, what about having a simple shell script called u2ps shipped and advertised
> in Core with a documented command line interface, and make it call paps as the
> implementation for now, but leave it open to switch to pango-view later on... 
> The interface should be quite simple, a cat-like tool with the following options:

It's not a bad idea though, I imagined gnome-u2ps which is on GNOME CVS, but
anyway. I don't know how it is recognized in the world, I at least got confused.
I like a concept to provide a standard interface, otherwise.

> That should be enough for now, and (except for footer?) paps supports the rest
> already, with different namings possibly.

Well, there are some required features from CUPS side too. using this as an
replacement of a commandline printing tool such as a2ps is also one of the way
though, the main thing are to work together on CUPS and to replaces the various
printing filters which is just kept to get CJK printing working as I described
earlier. no particular advantages there.
That is in my todo anyway.

> Another thing that should work in u2ps but is not currently working in paps is
> setting default paper size based on LC_PAPER.  We can make the wrapper figure
> out the paper and pass it to paps for now, and use it to set page size later
> with pango-view.

Ok, it's probably a feature that needs to be implemented.

------- Additional Comments From jkeating  2006-06-12 10:35 EST -------
Now needs libtool and doxygen build requirements.

E: paps zero-length /usr/share/doc/paps-0.6.6/NEWS

Thanks again. I've updated paps.spec in CVS and fixed in paps-0_6_6-4_fc6

Other than there being no version in the last changelog, this passes review. 
We'll need Jeremy's signoff to bring this into Core from Extras, and I'll need
to know how this will fit into Comps, how it will get installed on people's
machines.

For comps, I would expect we at least want it in place of where we currently
have h2ps and bg5ps.  We might actually want to just have cups depending on it
by default so that people always have it if it's not large (I wouldn't think it is)

Beyond that, I'm okay with this going in for now to replace h2ps and bg5ps but
with the understanding that it may be superceded again shortly.  And that having
a nice u2ps as in comment #11 would be a big positive thing.

So if this gets added in, do we need to block h2ps and bg5ps from the collection?

Akira, should this just be made a dep of cups to avoid further cups fanagling?

(In reply to comment #16)
> So if this gets added in, do we need to block h2ps and bg5ps from the collection?
> 
> Akira, should this just be made a dep of cups to avoid further cups fanagling?

Yes, I think so. it would be less troublesome to get this working. I will need
to file another bug to modify cjktexttops in cups to replace h2ps and bg5ps to
paps anyway. so I will notice the change of the dependency as well.

I've added it to dist-fc6 with owner of tagoh.  Please let me know when you've
fixed cups and I'll block h2ps and bg5ps from the distro.  It doesn't seem like
anything else is using it.

So can I import paps into the tree now?

yep.  Just let me know when the cups stuff is fixed.

cups-1.2.1-16 has a dependency of paps now.

h2ps and bg5ps blocked from dist-fc6 and removed from comps.

I have now ported paps to use the cairo-ps backend instead of libpaps.
Unfortunately it triggered a ghostscript bug. See:

    https://bugs.freedesktop.org/show_bug.cgi?id=8180

Regarding the rest of the changes described in this discussion, please make sure
that they are applied to the paps cvs, or filed as bugs/enhancements in the paps
sourceforge page.