This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 192912 - Review Request: paps
Review Request: paps
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FC-ACCEPT
  Show dependency treegraph
 
Reported: 2006-05-23 21:54 EDT by Akira TAGOH
Modified: 2013-01-09 20:24 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-30 09:39:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2006-05-23 21:54:14 EDT
Spec URL: http://cvs.fedora.redhat.com/viewcvs/devel/paps/paps.spec?root=extras&rev=1.10&view=auto
SRPM URL: http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/paps-0.6.6-1.fc6.src.rpm
Description: paps is a PostScript converter from plain text file using Pango.

Why I propose moving paps into Core is that to integrate CJK text printing filter and to replace h2ps and bg5ps so far and mpage soon.
Comment 3 Jesse Keating 2006-06-14 17:15:56 EDT
------- Additional Comments From jkeating@redhat.com  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
Comment 4 Jong Bae KO 2006-06-15 02:45:08 EDT
------- Additional Comments From jkeating@redhat.com  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.
Comment 5 Jong Bae KO 2006-06-15 02:55:44 EDT
------- Additional Comments From tagoh@redhat.com  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.
Comment 6 Jong Bae KO 2006-06-15 02:58:14 EDT
------- Additional Comments From jkeating@redhat.com  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.
Comment 7 Jong Bae KO 2006-06-15 02:59:43 EDT
------- Additional Comments From tagoh@redhat.com  2006-06-11 23:13 EST -------
Ok, updated in Extras CVS, except dist tag.
Comment 8 Jong Bae KO 2006-06-15 03:03:44 EDT
------- Additional Comments From besfahbo@redhat.com  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.
Comment 9 Jong Bae KO 2006-06-15 03:05:26 EDT
------- Additional Comments From tagoh@redhat.com  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.
Comment 10 Jong Bae KO 2006-06-15 03:07:27 EDT
------- Additional Comments From besfahbo@redhat.com  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.
Comment 11 Jong Bae KO 2006-06-15 03:09:38 EDT
------- Additional Comments From tagoh@redhat.com  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.
Comment 12 Jong Bae KO 2006-06-15 03:51:55 EDT
------- Additional Comments From jkeating@redhat.com  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
Comment 13 Akira TAGOH 2006-06-16 02:29:34 EDT
Thanks again. I've updated paps.spec in CVS and fixed in paps-0_6_6-4_fc6
Comment 14 Jesse Keating 2006-06-22 15:36:07 EDT
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.
Comment 15 Jeremy Katz 2006-06-22 16:32:21 EDT
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.
Comment 16 Jesse Keating 2006-06-23 12:03:55 EDT
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?
Comment 17 Akira TAGOH 2006-06-24 00:13:48 EDT
(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.
Comment 18 Jesse Keating 2006-06-26 13:16:43 EDT
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.
Comment 19 Akira TAGOH 2006-06-26 21:45:10 EDT
So can I import paps into the tree now?
Comment 20 Jesse Keating 2006-06-26 22:12:33 EDT
yep.  Just let me know when the cups stuff is fixed.
Comment 21 Akira TAGOH 2006-06-29 20:25:40 EDT
cups-1.2.1-16 has a dependency of paps now.
Comment 22 Jesse Keating 2006-06-30 09:39:49 EDT
h2ps and bg5ps blocked from dist-fc6 and removed from comps.
Comment 23 Dov Grobgeld 2006-09-11 01:46:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.