hpoj-devel — HPOJ development/support list

RE: [hpoj-devel] new I/O driver coming soon (second try)

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi,

First of all, I'd like to thank everybody for their interest and feedback
regarding the copyright and license on ptal-mlcd and hpoj in general.  A lot
of good points were raised, and I'll try to address them here.

But before I do that, I'd like to address the concerns that were raised
regarding the quality of print drivers, with which I can certainly
sympathize.  Actually, another division within HP is actively preparing
better inkjet drivers.  I'm not involved with that effort, but I took the
liberty of forwarding a couple of the relevant messages to several managers
and engineers who are involved.  It's a work in progress and no code has
been released yet, but you can get a sneak preview at
http://hpinkjet.sourceforge.net.  This driver was also demonstrated at
LinuxWorld Expo last month in the "e-mail garden".  I don't know exactly
when it will be released, but once I find out that it has been released I'll
be sure to make it known on the hpoj mailing lists.

Regarding the LGPL:

Although at first it might seem that the LGPL is the answer to this problem,
there are several reasons why it isn't appropriate in this situation,
particularly from an embedded systems perspective, which is where the new
MLC/1284.4 code comes from.  First and foremost is the fact that it would
potentially benefit competitors' proprietary products, which is highly
undesirable in the business I'm part of.  By releasing this code, the
intention for now is only to benefit free software, which is why the GPL
seems most appropriate.

The other problem with the LGPL is more of a practical nature.  When linking
with non-free software, there's a requirement to provide unlinked object
files to permit re-linking with newer versions of the LGPL code.  For an
embedded system, it may be difficult or impossible to get the new code onto
the device, especially if the firmware is burned into a ROM (which can't be
upgraded).

On the other hand, I have considered changing the license for PTAL (which
serves as the "official" API in this package) from GPL to LGPL.  At the
moment there doesn't appear to be a need for this, but I'll revisit this
question later if things change.

Joe Piolunek wrote:
> The IP 'transfer' plan reads like it was influenced by HP lawers
attempting 
> to adhere to some general policy. If that's the case, maybe Bruce Perens 
> could have a chat with them.
Actually, that was Bruce's suggestion, which was based on the example of Sun
and OpenOffice.  He also alluded to another possible strategy, where "the
contributor grant[s] HP separate and individual copyright, while they keep
their own copyright to the modification as well.  That means that either
party can do what they want with the code."  I can look into this if people
think it's better, but it may take more time to set up and consult with the
lawyers.

So to summarize what I currently have in mind:

The new changes will be released under the GPL (as is the case with the
existing hpoj code), but with an HP copyright.  The leveraged MLC/1284.4
portion of ptal-mlcd has to have the HP copyright because I developed it on
company time for actual products.  The remainder of my changes for the hpoj
project need to have the HP copyright because I'm now operating on behalf of
HP, rather than myself, as I was when I first joined this project.  I
haven't yet decided whether to retroactively change my existing copyrights
to HP or just apply it to new changes.

For everything in the hpoj codebase other than the leveraged MLC/1284.4
portion of ptal-mlcd, there will not be any requirement to re-assign
copyrights or otherwise give up any IP rights.  (I apologize if I offended
anybody by suggesting this as an option.)

As long as I'm responsible for maintaining both the free and HP-proprietary
versions of the MLC/1284.4 code, I'd like to keep them consistent (for the
sake of my own sanity:-).  To this end, if I accept contributions to this
portion of the codebase, I need to have some mechanism in place (such as the
various options already proposed) to permit me to incorporate contributions
onto both sides.  As the gatekeeper I would still have to scrutinize
submissions pretty carefully to ensure they were OK for both sides.  On the
other hand, I could just side-step the whole issue by maintaining this
portion of the code myself without any help.  And if I ever changed my mind
and decided to fork the code myself (i.e. if I changed jobs and no longer
was responsible for both versions), then the issue of maintaining
consistency would become irrelevant anyway.

One other question I should probably research is whether small changes, such
as a one-line bug fix, are different from large changes, and if so, what the
threshold is.  For Sun OpenOffice, I think the threshold is 10 lines.

Keep in mind that the license is GPL throughout the hpoj package, in
particular "version 2 or at your option any later version".  This means that
regardless of any difficulties imposed on submitting changes to the
"official" version I maintain, one would be free to fork their own version
from the GPLed "official" version (with or without any existing
contributions) and maintain it separately, with no requirement to push the
changes back to HP, as long as they abide by the GPL.  Also, I should point
out that in general, the copyright holders, whether HP or anybody else, have
the right to unanimously choose to release the same piece of code under
multiple licenses, as is the case here with the new MLC/1284.4 code.
However, the GPL does not permit revocation of code that has been released
under the GPL even if newer versions of the code have a different license,
so there are no worries there.

At this point, all I have left to do before checking in the new code is to
finalize the details about the dual-licensing and consistency of the
MLC/1284.4 code, and to finish rearranging the codebase and build process to
integrate the new functionality.  I look forward to any comments about what
I had to say here.  :-)

David

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Robert G. B. <rg...@ph...>]

On Thu, 1 Mar 2001, Judd Montgomery wrote:

> "Robert G. Brown" wrote:
> >
> > On Thu, 1 Mar 2001, Judd Montgomery wrote:
> >
> > > Are there any drivers out there that are better than the cdj970 and/or
> > > ghostscript?  I really want to make this work if possible.
> >
> > I'm not sure about what you mean by "better".  My current setup works
> > perfectly well for text, and is a "faithful image" of color -- its just
> > that the colors and dot resolution aren't right for photo quality
> > output.  It is fine for primary color fliers and the like, not so good
> > if one has a 3.3 megapixel digital camera and had hopes/illusions of
> > doing photo art (or even simple, adequate, photo portrature of your
> > family).
> >
>
> I'd be happy with that.
> I'm using the duplex printing feature if that matters.  When printing
> text (postscript), it prints more than an extra inch of margin at the
> top and the text then runs all the way to the bottom of the paper.
> Sometimes I've seen it print part of page 2 on the bottom of page one.
> If I use gv, or gs and look at the postscript it looks fine.  So, it is
> the print driver doing this.

Actually, this might or might not be true.  Check the paper type
definition in your postscript setup.  I have to leave just now, but when
I get home I'll try to find just where that is stored.  I'll bet that it
isn't set to ordinary 8.5x11 paper.

>
> > What linux distribution are you using?  I'd be happy to share my
> > "current best" printer filter setup, developed for Red Hat, if that is
> > what you need.  If it is just a stair-step effect type problem, the Red
> > Hat printtool will fix that for you.  If you're not using RH, then
> > you'll have to take the filter setup and hack it and install it in your
> > own filter arrangement.
> >
>
> I use Slackware and just write my own filters in perl.
> I'm a programmer so I can hack what ever you have and will try that.
> Thanks.  You can send it private if you don't want to clog up the list.

Will do, when I get home.  Later.

>
> Judd
>
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Robert G. B. <rg...@ph...>]

On Thu, 1 Mar 2001, Joe Piolunek wrote:

> I'm not familiar with the LGPL, but Robert's suggestion sounds like it should
> be taken seriously.

Sorry, should have included a URL:

http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses

(second on the list at this entry).  It is worth it for any open source
developer to skim this list (at least) and look at the staggering array
of copy[right/left] choices.  It is also worthwhile to note the
existence of both the Gnu Documentation License and the Open Publication
License, which is similar but reserves certain commercial rights to the
original author.

These "alternative" (but still open) licenses are often useful when
circumstance or a desire to make money dictate a relationship with a
corporate entity (like a publishing house or a technology company) but
where one wishes, nevertheless to ensure that the source and (possibly)
limited rights remain open to anyone who doesn't plan to make money with
it.  That is, a reasonable open source philosophy for some folks and
some kind of work might be "anybody can get or use this for free
themselves, but if you want to try to resell it at a net profit of real
money I (and/or my corporate agents) get some".

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Judd M. <ju...@jp...>]

"Robert G. Brown" wrote:
> 
> On Thu, 1 Mar 2001, Judd Montgomery wrote:
> 
> > Are there any drivers out there that are better than the cdj970 and/or
> > ghostscript?  I really want to make this work if possible.
> 
> I'm not sure about what you mean by "better".  My current setup works
> perfectly well for text, and is a "faithful image" of color -- its just
> that the colors and dot resolution aren't right for photo quality
> output.  It is fine for primary color fliers and the like, not so good
> if one has a 3.3 megapixel digital camera and had hopes/illusions of
> doing photo art (or even simple, adequate, photo portrature of your
> family).
> 

I'd be happy with that.
I'm using the duplex printing feature if that matters.  When printing
text (postscript), it prints more than an extra inch of margin at the
top and the text then runs all the way to the bottom of the paper. 
Sometimes I've seen it print part of page 2 on the bottom of page one. 
If I use gv, or gs and look at the postscript it looks fine.  So, it is
the print driver doing this.

> What linux distribution are you using?  I'd be happy to share my
> "current best" printer filter setup, developed for Red Hat, if that is
> what you need.  If it is just a stair-step effect type problem, the Red
> Hat printtool will fix that for you.  If you're not using RH, then
> you'll have to take the filter setup and hack it and install it in your
> own filter arrangement.
> 

I use Slackware and just write my own filters in perl.
I'm a programmer so I can hack what ever you have and will try that. 
Thanks.  You can send it private if you don't want to clog up the list.

Judd

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Joe P. <joe...@sn...>]

On Thursday 01 March 2001 01:29, David wrote:

<...>
>
> In the meantime, I'd like to take this opportunity to solicit ideas and
> feedback on a particular license/copyright issue.  I intend to license
> ptal-mlcd under the GPL, as has been done already with the rest of the hpoj
> package, to guarantee its status as free software.  The difference here is
> that some of the code in ptal-mlcd (in particular, the portion that
> actually implements the MLC/1284.4 transport) is also used by HP in non-GPL
> products. That in and of itself isn't a problem, since as the copyright
> holder HP may license the code simultaneously under the GPL as well as
> under a traditional proprietary license.  The problem arises when accepting
> contributions to this code from outside of HP, because I need to be able to
> incorporate those changes into the non-GPL version.  This makes my job much
> easier, since I'm responsible for maintaining both versions, and I want to
> keep them consistent for now to facilitate further updates.  I plan to
> handle this issue by requiring people who contribute changes to the
> transport portion of ptal-mlcd to assign copyright of the changes to HP,
> probably either by signing and sending in a paper form agreeing to this (as
> Sun does with http://openoffice.org), or by including with each submitted
> patch a canned statement to this effect.

David:

I'm glad that HP has supported you in your efforts regarding the hpoj 
project. It has resulted in many improvements. 

In spite of recent statements from HP about being "ready to walk the walk", 
it still seems a little wobbly.

It seems to me that if HP really wants Linux/*BSD, etc. to support its 
products, it would gratefully supply any necessary information to developers 
willing to help make it possible. I don't yet see that happening.

HP should definitely not (IMO) attempt to force open source contributors to 
give away their own Intellectual Property for what amounts to no 
compensation. Few people (if any) would be willing to do so under those 
conditions.

The IP 'transfer' plan reads like it was influenced by HP lawers attempting 
to adhere to some general policy. If that's the case, maybe Bruce Perens 
could have a chat with them.


>
> Keep in mind that the intent here is not to take unfair advantage of
> anybody's efforts.  In addition to making it easier for me to maintain, it
> also makes it easier for HP to defend against copyright infringement;
> otherwise, we would have to get every copyright holder to become involved.

An alternative would be for everyone who contributed to the project 
(including HP) to assign to the Free Software Foundation the IP rights to 
their contributions, with HP promising to pay for defending against 
infringement, whatever the source. It probably could be justified as a tax 
write-off. I doubt HP will agree to do that, though. I only say it because if 
it could be done, it might satisfy most people's concerns, including those of 
HP that you stated above.


> I would like to know if anybody has comments or concerns regarding this
> copyright-assignment proposal.  At the very least it will apply to the
> MLC/1284.4 portion of ptal-mlcd, and it may apply to the entirety of
> ptal-mlcd.  I haven't yet decided if it will apply to other parts of the
> codebase that I (and by extension HP) contributed.  However, I personally
> am planning on transferring my copyrights (i.e. on PTAL) to HP, since my
> involvement is finally becoming officially sponsored by HP, as opposed to
> its being a personal project the way it has been for me so far.  Most of
> the other code (ieee12844, ojlib, apps/print, and apps/cmdline) will go
> away in 0.8 (being replaced by PTAL equivalents), so there won't be any
> question about that in the first place.  The only remaining part of the
> codebase that I didn't develop would be xojpanel.  I think it will be fine
> to keep the copyright on xojpanel the way it is currently (unless Joe and
> Andreas really want to transfer it).

My IP rights to xojpanel (about 95% of the code plus graphics) won't be given 
to HP.

>
> Thanks in advance for any comments on these matters, and stay tuned for the
> actual code in the near future, assuming there isn't so much dissent here
> that I have to go back to the drawing board.  :-)
>

I'm not familiar with the LGPL, but Robert's suggestion sounds like it should 
be taken seriously.

-- 
Joe

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Carlos P. <cp...@pu...>]

i'd say suggest the contributions to be lgpl, so that hp can use
them, but asking about giving up the copyright is a bit too much
(now, if the contribs are too small, then that is probably ok).

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Robert G. B. <rg...@ph...>]

On Thu, 1 Mar 2001, Judd Montgomery wrote:

> Are there any drivers out there that are better than the cdj970 and/or
> ghostscript?  I really want to make this work if possible.

I'm not sure about what you mean by "better".  My current setup works
perfectly well for text, and is a "faithful image" of color -- its just
that the colors and dot resolution aren't right for photo quality
output.  It is fine for primary color fliers and the like, not so good
if one has a 3.3 megapixel digital camera and had hopes/illusions of
doing photo art (or even simple, adequate, photo portrature of your
family).

What linux distribution are you using?  I'd be happy to share my
"current best" printer filter setup, developed for Red Hat, if that is
what you need.  If it is just a stair-step effect type problem, the Red
Hat printtool will fix that for you.  If you're not using RH, then
you'll have to take the filter setup and hack it and install it in your
own filter arrangement.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Judd M. <ju...@jp...>]

"Robert G. Brown" wrote:
> 
> (Sorry about the semi-rant, but this is a moderately serious problem and
> HP needs to become aware of it and direct some resources to it -- I
> cannot even recommend their printer/scanner to most of my friends at
> this point on the basis of the quality I've been able to achieve with
> 20-40 hours of my own time invested.  This is in the "not ready for
> linux prime time" category and very definitely is costing them sales.)
> 

Yes, it is costing them sales.  I just bought my G95 after reading the
hpoj sourceforge website and the HP website.  I thought this was a
fairly well supported printer.  It certainly wasn't inexpensive.  I'm
currently using the ghostscript cdj970 driver and it just isn't
acceptable.  What is even more agrivating is that I also have some
margin issues in Linux and Windows.  I usually never use technical
support, but decided to try HP.  I told them I was using Linux and
Windows.  I got the typical "We don't support Linux" answer and was
asked more questions.  The next email from them was basically blowing me
off and not bothering to answer my problems with the margins.

I'm about ready to send the printer back and I'm sure a returned sale
costs more than a lost sale.

Are there any drivers out there that are better than the cdj970 and/or
ghostscript?  I really want to make this work if possible.

Judd

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Robert G. B. <rg...@ph...>]

On Thu, 1 Mar 2001, Erik Hendrix wrote:

> I have a OfficeJet G55 and currently I'm using the cpdj500 filter. Which
> gives bad quality compared to what my printer can do.
>
> Now I understand one can use the 970 but having looked at it, there are a
> lot of steps there to do without clear English instructions.
>
> It would be nice if we would be able to just get a filter or so and put
> it on the system instead of having to go out, getting Ghostscript and the
> driver and then compiling, making changes etc...

Hear, hear!  I definitely second this.  I've spent a full ink cartridge
pair and $20-30 worth of high-quality paper on this over three months
and still get most unsatisfactory (nowhere near "photo-quality")
results.  I've gone through cpdj500 (with various gamma settings, color
settings, and any other tunings I can figure out) and have even tried
the new gimp printer driver, as it was rumored that this provides a
ghostscript-independent device layer that can be carefully tuned for
gamma and so forth, but neither of these come close to either the
quality of the printer used as a color photocopier or the onscreen
quality of the underlying jpeg (or etc.)  photographs, even at pixel
resolutions that should be 1:1 mappings of the onscreen image.

Stippled images produced by some driver setups have annoying granularity
and a lack of sharp images and still poor color, bitmap images produced
by other drivers have better pixel granularity (although still nothing
like I imagine I should be getting) but even worse color.  The colormap
problems aren't ones that can be resolved by monkeying with linear
three-knob gamma -- I've turned those knobs pretty much every way they
can turn and still get poor blue/whites, overemphasized reds and greens,
and a consequently "muddy" image.  They require a proper nonlinear map.

Although I haven't taken the relatively drastic step of hooking the
printer up to my one dual boot laptop and actually checking out the
Windows photo-print resolution, I cannot imagine anyone buying the
printer and attaching it to any linux box for the primary purpose of
printing color photographs or images with the best I've achieved so far.
Since they continue to sell, I imagine that the Windows drivers and
gamma settings are pretuned for much better output.  It would be truly
nice if HP would help create a linux filter set that has a "perfect"
colormap/pixelmap conversion for this kind of printer.  I'd actually
suggest that they go with the gimp plugin approach, as this seems a lot
more portable than the yet-another-ghostscript-filter approach.

It is great to have a good printer/kernel interface so that both
scanning and printing "work" and to reduce the number and complexity of
the driver modules that must be inserted, but at this point the burning
need is clearly for improved color print quality.  It would be nice for
HP to both contribute the colormappings they must already have developed
for e.g. WinXX (the core of which should be portable/reusable code,
after all) and fund the several thousand pages of test printing required
to build and fine-tune a gimp plugin or other portable filter package,
possibly on a printer by printer basis for their various officejets
(presuming that some might require different maps).

A proper job of this should mean that they can eventually ship a
build-ready package with their officejet (and probably other) printers
and add the word "Linux" to the list of supported environments right
their on the printer boxes.  This will make them money for sure -- HP
has an excellent reputation and the G55's and other color combo office
printer/scanners/copiers are a great solution for many a University
research group or small business department that relies on linux,
including my own.  Until this is fixed, though, there is no way I'm
going to buy another one -- I'm even considering buying one of their
inexpensive competitors (e.g. a Canon) just because their print
drivers/filters are known to exist and work excellently well on
photographs.

(Sorry about the semi-rant, but this is a moderately serious problem and
HP needs to become aware of it and direct some resources to it -- I
cannot even recommend their printer/scanner to most of my friends at
this point on the basis of the quality I've been able to achieve with
20-40 hours of my own time invested.  This is in the "not ready for
linux prime time" category and very definitely is costing them sales.)

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Erik H. <hen...@ho...>]

<html><DIV>
<P>Can I just first of all say : GREAT. It seems to me that thanks to this you will be able to provide better support for our printers in Linux. And I can only be happy about that.</P>
<P>So my thanks go out to you, who I believe to have been pushing for this not to mention do development on your own to give us printing capabilities and to HP management who've decided on this.</P>
<P>&nbsp;</P>
<P>Since it seems that HP is warming up for Linux, might it be possible that HP will also start making the PPD files etc.. for printers? Or release more documentation for it so that someone with the right knowledge will be able to use this.</P>
<P>I have a OfficeJet G55 and currently I'm using the cpdj500 filter. Which gives bad quality compared to what my printer can do.</P>
<P>Now I understand one can use the 970 but having looked at it, there are a lot of steps there to do without clear English instructions. </P>
<P>It would be nice if we would be able to just get a filter or so and put it on the system instead of having to go out, getting Ghostscript and the driver and then compiling, making changes etc...</P>
<P>&nbsp;</P>
<P>Thank you.<BR><BR></P></DIV>
<DIV></DIV>
<DIV></DIV>&gt;From: "PASCHAL,DAVID (HP-Roseville,ex1)" <DAV...@HP...>
<DIV></DIV>&gt;I am pleased to report that I have gotten permission from my management to 
<DIV></DIV>&gt;release the new user-mode I/O driver ("ptal-mlcd") I've been working on 
<DIV></DIV>
<DIV>&nbsp;</DIV><br clear=all><hr>Get your FREE download of MSN Explorer at <a href="http://explorer.msn.com">http://explorer.msn.com</a><br></p></html>

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Robert G. B. <rg...@ph...>]

On Wed, 28 Feb 2001, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> In the meantime, I'd like to take this opportunity to solicit ideas and
> feedback on a particular license/copyright issue.  I intend to license
> ptal-mlcd under the GPL, as has been done already with the rest of the hpoj
> package, to guarantee its status as free software.  The difference here is
> that some of the code in ptal-mlcd (in particular, the portion that actually
> implements the MLC/1284.4 transport) is also used by HP in non-GPL products.
> That in and of itself isn't a problem, since as the copyright holder HP may
> license the code simultaneously under the GPL as well as under a traditional
> proprietary license.  The problem arises when accepting contributions to
> this code from outside of HP, because I need to be able to incorporate those
> changes into the non-GPL version.  This makes my job much easier, since I'm
> responsible for maintaining both versions, and I want to keep them
> consistent for now to facilitate further updates.  I plan to handle this
> issue by requiring people who contribute changes to the transport portion of
> ptal-mlcd to assign copyright of the changes to HP, probably either by
> signing and sending in a paper form agreeing to this (as Sun does with
> http://openoffice.org), or by including with each submitted patch a canned
> statement to this effect.
>
> Keep in mind that the intent here is not to take unfair advantage of
> anybody's efforts.  In addition to making it easier for me to maintain, it
> also makes it easier for HP to defend against copyright infringement;
> otherwise, we would have to get every copyright holder to become involved.
> On the other hand, since this is GPL code, one would be perfectly free to
> "fork" the code into a separate project and make their own changes without
> contributing them directly to this project and assigning copyright to HP, as
> long as they abide by the GPL.  Hopefully that won't be necessary, but
> there's nothing wrong with it.  In any case, as the gatekeeper of both
> versions of the code I will need to be fairly conservative about what
> changes I accept to the MLC/1284.4 portion of ptal-mlcd, so this issue may
> not come up much or at all anyway.
>
> I would like to know if anybody has comments or concerns regarding this
> copyright-assignment proposal.  At the very least it will apply to the

Why not simply split off all of the core code that you wish to share
into a Lesser GPL module (used when folks wish to permit incorporation
of GPL stuff into proprietary programs.  That's what this is for, after
all.  The shell routines that call things from this module can still be
full GPL.

That way everything in the project remains open source and freely
reusable without worrying about having to split off open/closed versions
or re-engineer or reverse engineer any particular part of the shared
code.  Thus HP can contribute changes they might need to any part of the
LGPL portion (as long as you're willing to work with the GPL portion so
that it still works) as can anyone else, but HP is also free to link the
LGPL object modules into their proprietary stuff without having to
reveal its source.

I at least am perfectly comfortable with this.  To me the real open
source issue is the protection provided by GPL's in general from
companies like HP deciding to grab the LGPL modules, hack them a bit,
and then copyright or patent things therein so that the original
creators are no longer free to use them.  I don't think HP has any
interest in that game anyway, as they are a highly innovative company
and don't really need to steal (for it really is a kind of intellectual
theft) but the LGPL suffices to prevent it in any event.

This does mean (I believe) that HP will be de facto obligated to not in
the future attempt to copyright or patent code that is itself derivative
from what is in the LGPL module or library.  It would also probably be
the best idea all around if the module itself has a fairly clearly
specified API and is indeed a library (that is, doesn't contain any of
the OS-specific "shell" portions or potentially proprietary processing
algorithm portions that HP might want to keep or that GPL contributors
might want and expect to be truly openly shared).

In this case, you shouldn't need any fancy documentation or signed
agreements -- you only need to decide which portions should be full GPL
and which should be lesser and place the appropriate copyright/license
headers in each.  If you split off the LGPL parts into a source
directory for a LGPL-only library, so much the cleaner.  This way the
full source of hpoj stuff will remain rigorously open source, the stuff
you've written or that others have contributed can remain full GPL, and
stuff that hp has contributed and/or wants to be able to share and
incorporate into proprietary stuff can be LGPL.

BTW, looking forward to 0.8, especially since I'm up to RH 7.0 and
looking hard at installing 7.1beta, which uses a 2.4 kernel.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] new I/O driver coming soon (second try)

[Christopher Y. <cy...@wc...>]

I have a few reservations about HP holding the copyright to the entire 
codebase.  I would personally feel better if at least one complete 
release is released completely under the GPL without any furthur 
limitations.

My reasoning for taking this position is simple.  If HP owns the 
copyright to all of the code, they have the authority (PLEASE!  Someone 
correct me if I am wrong) to take future releases of the code and change 
the license.  This was done with SSH if I remember correctly and thus 
was formed the OpenSSH project.  There is now a huge debate about 
trademarking issues in that arena as a result of a licensing change made 
to open source code.

I don't wish to hurt the development of software that I believe makes 
Linux more attractive and allows some really good, useful hardware to be 
available to Linux users.  I just worry about commercial companies 
controlling Free Software code in this manner.

If we have one release that is completely GPL (and without copyright 
restrictions), then the community can decide to fork off the code and 
not have to get permission from HP to change licensing (if ever there 
arose a need to do so - new version of GPL, the need to license certain 
pieces under LGPL).  Changing the license would of course require all of 
the ppl who have contributed code (which should be tracked properly in 
the AUTHORS/LICENSE files) but at least the community could make that 
decision without limitations.

I'm not an expert on licensing and the GPL, but I think my concerns are 
valid.  Again, I don't wish to limit anything, just would like this 
issue to at least be debated a little bit.  I reiterate that I am not a 
licensing/copyright expert and would very much appreciate someone who 
can provide some insight into the potenial issues to speak up.

Chris

PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> (Sorry, I accidentally pressed Ctrl-Enter ("Send" in Outlook) before I was
> done writing this message!  Let's try this again, and please disregard the
> previous partial message...)
> 
> Hi,
> 
> I am pleased to report that I have gotten permission from my management to
> release the new user-mode I/O driver ("ptal-mlcd") I've been working on
> lately.  There are still a few formalities I have to take care of first
> before I can do that, but at this point I can say with fairly high
> confidence that I will be able to start checking it into CVS within the next
> 2-4 weeks (or earlier if possible).  I just updated the web page, especially
> http://hpoj.sourceforge.net/todo.shtml, to indicate the most recent plans.
> The most significant changes include greatly improved stability, USB
> support, and parallel-port support for probably any version of Linux (not
> just 2.2 and 2.4).  I will send out another announcement when that's done to
> give people an opportunity to start playing around with it, but I will still
> have some additional development to do before I can put out 0.8.
> Nevertheless, printing and scanning already work well over both parallel and
> USB.
> 
> In the meantime, I'd like to take this opportunity to solicit ideas and
> feedback on a particular license/copyright issue.  I intend to license
> ptal-mlcd under the GPL, as has been done already with the rest of the hpoj
> package, to guarantee its status as free software.  The difference here is
> that some of the code in ptal-mlcd (in particular, the portion that actually
> implements the MLC/1284.4 transport) is also used by HP in non-GPL products.
> That in and of itself isn't a problem, since as the copyright holder HP may
> license the code simultaneously under the GPL as well as under a traditional
> proprietary license.  The problem arises when accepting contributions to
> this code from outside of HP, because I need to be able to incorporate those
> changes into the non-GPL version.  This makes my job much easier, since I'm
> responsible for maintaining both versions, and I want to keep them
> consistent for now to facilitate further updates.  I plan to handle this
> issue by requiring people who contribute changes to the transport portion of
> ptal-mlcd to assign copyright of the changes to HP, probably either by
> signing and sending in a paper form agreeing to this (as Sun does with
> http://openoffice.org), or by including with each submitted patch a canned
> statement to this effect.
> 
> Keep in mind that the intent here is not to take unfair advantage of
> anybody's efforts.  In addition to making it easier for me to maintain, it
> also makes it easier for HP to defend against copyright infringement;
> otherwise, we would have to get every copyright holder to become involved.
> On the other hand, since this is GPL code, one would be perfectly free to
> "fork" the code into a separate project and make their own changes without
> contributing them directly to this project and assigning copyright to HP, as
> long as they abide by the GPL.  Hopefully that won't be necessary, but
> there's nothing wrong with it.  In any case, as the gatekeeper of both
> versions of the code I will need to be fairly conservative about what
> changes I accept to the MLC/1284.4 portion of ptal-mlcd, so this issue may
> not come up much or at all anyway.
> 
> I would like to know if anybody has comments or concerns regarding this
> copyright-assignment proposal.  At the very least it will apply to the
> MLC/1284.4 portion of ptal-mlcd, and it may apply to the entirety of
> ptal-mlcd.  I haven't yet decided if it will apply to other parts of the
> codebase that I (and by extension HP) contributed.  However, I personally am
> planning on transferring my copyrights (i.e. on PTAL) to HP, since my
> involvement is finally becoming officially sponsored by HP, as opposed to
> its being a personal project the way it has been for me so far.  Most of the
> other code (ieee12844, ojlib, apps/print, and apps/cmdline) will go away in
> 0.8 (being replaced by PTAL equivalents), so there won't be any question
> about that in the first place.  The only remaining part of the codebase that
> I didn't develop would be xojpanel.  I think it will be fine to keep the
> copyright on xojpanel the way it is currently (unless Joe and Andreas really
> want to transfer it).
> 
> Thanks in advance for any comments on these matters, and stay tuned for the
> actual code in the near future, assuming there isn't so much dissent here
> that I have to go back to the drawing board.  :-)
> 
> 
> Allen Barnett wrote:
> 
>> Subject: [hpoj-devel] Choice of Devices
>> I'm trying to decide between an HP G85 and a G95 (which is 
>> evidently the
>> same machine as the G85, except you get a JetDirect 170 with it). I
>> already have a B&W PostScript laser printer connected to my parallel
>> port which I am loath to give up. So, I either need to be able to
>> connect the new device to a USB port or get the G95 and connect it to
>> the network. I have no real need currently for a networked printer,
>> however. Also in the mix: I need to run a 2.4 kernel to support some
>> other hardware and there (still?) appear to be some issues with its
>> parallel port support.
>> 
>> I guess my question is: Is USB connectivity for the the G series going
>> to happen in the next month or so, or should I go ahead and 
>> get the G95.
>> (Or better still, is there some way I could contribute to making this
>> happen?)
> 
> 
> 
> Anthony Segredo wrote:
> 
>> Subject: Linux 2.0.36 Officejet R40 support
>> I am running the 2.0.36 kernel from the Redhat 5.2 distribution. I see 
>> that the Officejet support is only for kernels 2.2.x and 2.4.x, is this 
>> because of the parport driver? Is it possible that if I install and 
>> build the parport source that the Officejet driver will work on 2.0.36?
>> Where should your download code be rooted?
>> 
>> I'm really pleased at the idea that I no longer have to put files in 
>> the Windows partition to print them but am a little scared at the idea 
>> of downloading and building the whole kernel although I have customized 
>> and rebuilt the 2.0.36 kernel. I am a software professional but a Linux 
>> newbie.
> 
> 
> Hi, Anthony.  I would recommend against trying to back-port the "parport"
> code into 2.0.  It also might be kind of tricky to upgrade the kernel on
> your system, because you might need to upgrade various other system-level
> utilities as well.  If you want this to work right away you could upgrade
> your entire system to a more recent version of RedHat or another
> distribution.  However, I think you would be better off waiting for the new
> driver (see above).  That way you can help test it on kernel 2.0.  Also,
> please subscribe to hpoj-announce and hpoj-devel if you haven't already so
> that you can fully participate in testing and debugging.
> 
> David

-- 

Christopher M. Young,
SCSA, RHCE, MSCE, CCNA, CCA

PTC/GTC Systems Engineer,
World Commerce Online
cy...@wc...

[hpoj-devel] new I/O driver coming soon

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi,

I am pleased to report that I have gotten permission from my management to
release the new user-mode I/O driver ("ptal-mlcd") I've been working on
lately.  There are still a few formalities I have to take care of first
before I can do that, but at this point I can say with fairly high
confidence that I will be able to start checking it into CVS within the next
2-4 weeks (or earlier if possible).  I just updated the web page, especially
http://hpoj.sourceforge.net/todo.shtml, to indicate the most recent plans.
The most significant changes include greatly improved stability, USB
support, and parallel-port support for probably any version of Linux (not
just 2.2 and 2.4).

In the meantime, I'd like to take this opportunity to solicit ideas and
feedback on a particular license/copyright issue.  I intend to license
ptal-mlcd under the GPL, as has been done already with the rest of the hpoj
package, to guarantee its status as free software.  The difference here is
that some of the code in ptal-mlcd (in particular, the portion that actually
implements MLC/1284.4) is also used by HP in non-GPL products.  That in and
of itself isn't a problem, since as the copyright holder HP may license the
code simultaneously under the GPL as well as under a traditional proprietary
license.  The problem arises when accepting contributions to this code from
outside of HP, because I need to be able to incorporate those changes into
the non-GPL version.  This makes my job much easier, since I'm responsible
for maintaining both versions, and I want to keep them consistent for now.
I plan to handle this issue by requiring people who contribute changes to
ptal-mlcd to assign copyright of the changes to HP, probably either by
signing and sending in a paper form agreeing to this (as Sun does with
http://openoffice.org), or by including with each submitted patch a canned
statement to this effect.

I would like to know if anybody has comments or concerns regarding this
copyright-assignment proposal.  At the very least it will apply to the
MLC/1284.4 portion of ptal-mlcd.  I haven't yet decided if it will apply to
other parts of the codebase that I (and by extension HP) contributed.
However, I personally am planning on transferring my copyrights (i.e. on
PTAL) to HP, since this i

Keep in mind that the intent is not to take unfair advantage of anybody's
efforts.  In addition to making 
, and it also makes it easier for HP to defend against copyright
infringement.


On the other hand, since this is GPL code, one would be perfectly free to
"fork" the code into a separate project and make their own changes without
contributing them directly to this project and assigning copyright to HP, as
long as they abide by the GPL.

David

Allen Barnett wrote:
> Subject: [hpoj-devel] Choice of Devices
> I'm trying to decide between an HP G85 and a G95 (which is 
> evidently the
> same machine as the G85, except you get a JetDirect 170 with it). I
> already have a B&W PostScript laser printer connected to my parallel
> port which I am loath to give up. So, I either need to be able to
> connect the new device to a USB port or get the G95 and connect it to
> the network. I have no real need currently for a networked printer,
> however. Also in the mix: I need to run a 2.4 kernel to support some
> other hardware and there (still?) appear to be some issues with its
> parallel port support.
> 
> I guess my question is: Is USB connectivity for the the G series going
> to happen in the next month or so, or should I go ahead and 
> get the G95.
> (Or better still, is there some way I could contribute to making this
> happen?)


Anthony.F.Segredo wrote:
> Subject: Linux 2.0.36 Officejet R40 support
> I am running the 2.0.36 kernel from the Redhat 5.2 distribution. I see 
> that the Officejet support is only for kernels 2.2.x and 2.4.x, is this 
> because of the parport driver? Is it possible that if I install and 
> build the parport source that the Officejet driver will work on 2.0.36?
> Where should your download code be rooted?
>
> I'm really pleased at the idea that I no longer have to put files in 
> the Windows partition to print them but am a little scared at the idea 
> of downloading and building the whole kernel although I have customized 
> and rebuilt the 2.0.36 kernel. I am a software professional but a Linux 
> newbie.

[hpoj-devel] new I/O driver coming soon (second try)

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

(Sorry, I accidentally pressed Ctrl-Enter ("Send" in Outlook) before I was
done writing this message!  Let's try this again, and please disregard the
previous partial message...)

Hi,

I am pleased to report that I have gotten permission from my management to
release the new user-mode I/O driver ("ptal-mlcd") I've been working on
lately.  There are still a few formalities I have to take care of first
before I can do that, but at this point I can say with fairly high
confidence that I will be able to start checking it into CVS within the next
2-4 weeks (or earlier if possible).  I just updated the web page, especially
http://hpoj.sourceforge.net/todo.shtml, to indicate the most recent plans.
The most significant changes include greatly improved stability, USB
support, and parallel-port support for probably any version of Linux (not
just 2.2 and 2.4).  I will send out another announcement when that's done to
give people an opportunity to start playing around with it, but I will still
have some additional development to do before I can put out 0.8.
Nevertheless, printing and scanning already work well over both parallel and
USB.

In the meantime, I'd like to take this opportunity to solicit ideas and
feedback on a particular license/copyright issue.  I intend to license
ptal-mlcd under the GPL, as has been done already with the rest of the hpoj
package, to guarantee its status as free software.  The difference here is
that some of the code in ptal-mlcd (in particular, the portion that actually
implements the MLC/1284.4 transport) is also used by HP in non-GPL products.
That in and of itself isn't a problem, since as the copyright holder HP may
license the code simultaneously under the GPL as well as under a traditional
proprietary license.  The problem arises when accepting contributions to
this code from outside of HP, because I need to be able to incorporate those
changes into the non-GPL version.  This makes my job much easier, since I'm
responsible for maintaining both versions, and I want to keep them
consistent for now to facilitate further updates.  I plan to handle this
issue by requiring people who contribute changes to the transport portion of
ptal-mlcd to assign copyright of the changes to HP, probably either by
signing and sending in a paper form agreeing to this (as Sun does with
http://openoffice.org), or by including with each submitted patch a canned
statement to this effect.

Keep in mind that the intent here is not to take unfair advantage of
anybody's efforts.  In addition to making it easier for me to maintain, it
also makes it easier for HP to defend against copyright infringement;
otherwise, we would have to get every copyright holder to become involved.
On the other hand, since this is GPL code, one would be perfectly free to
"fork" the code into a separate project and make their own changes without
contributing them directly to this project and assigning copyright to HP, as
long as they abide by the GPL.  Hopefully that won't be necessary, but
there's nothing wrong with it.  In any case, as the gatekeeper of both
versions of the code I will need to be fairly conservative about what
changes I accept to the MLC/1284.4 portion of ptal-mlcd, so this issue may
not come up much or at all anyway.

I would like to know if anybody has comments or concerns regarding this
copyright-assignment proposal.  At the very least it will apply to the
MLC/1284.4 portion of ptal-mlcd, and it may apply to the entirety of
ptal-mlcd.  I haven't yet decided if it will apply to other parts of the
codebase that I (and by extension HP) contributed.  However, I personally am
planning on transferring my copyrights (i.e. on PTAL) to HP, since my
involvement is finally becoming officially sponsored by HP, as opposed to
its being a personal project the way it has been for me so far.  Most of the
other code (ieee12844, ojlib, apps/print, and apps/cmdline) will go away in
0.8 (being replaced by PTAL equivalents), so there won't be any question
about that in the first place.  The only remaining part of the codebase that
I didn't develop would be xojpanel.  I think it will be fine to keep the
copyright on xojpanel the way it is currently (unless Joe and Andreas really
want to transfer it).

Thanks in advance for any comments on these matters, and stay tuned for the
actual code in the near future, assuming there isn't so much dissent here
that I have to go back to the drawing board.  :-)


Allen Barnett wrote:
> Subject: [hpoj-devel] Choice of Devices
> I'm trying to decide between an HP G85 and a G95 (which is 
> evidently the
> same machine as the G85, except you get a JetDirect 170 with it). I
> already have a B&W PostScript laser printer connected to my parallel
> port which I am loath to give up. So, I either need to be able to
> connect the new device to a USB port or get the G95 and connect it to
> the network. I have no real need currently for a networked printer,
> however. Also in the mix: I need to run a 2.4 kernel to support some
> other hardware and there (still?) appear to be some issues with its
> parallel port support.
> 
> I guess my question is: Is USB connectivity for the the G series going
> to happen in the next month or so, or should I go ahead and 
> get the G95.
> (Or better still, is there some way I could contribute to making this
> happen?)


Anthony Segredo wrote:
> Subject: Linux 2.0.36 Officejet R40 support
> I am running the 2.0.36 kernel from the Redhat 5.2 distribution. I see 
> that the Officejet support is only for kernels 2.2.x and 2.4.x, is this 
> because of the parport driver? Is it possible that if I install and 
> build the parport source that the Officejet driver will work on 2.0.36?
> Where should your download code be rooted?
>
> I'm really pleased at the idea that I no longer have to put files in 
> the Windows partition to print them but am a little scared at the idea 
> of downloading and building the whole kernel although I have customized 
> and rebuilt the 2.0.36 kernel. I am a software professional but a Linux 
> newbie.

Hi, Anthony.  I would recommend against trying to back-port the "parport"
code into 2.0.  It also might be kind of tricky to upgrade the kernel on
your system, because you might need to upgrade various other system-level
utilities as well.  If you want this to work right away you could upgrade
your entire system to a more recent version of RedHat or another
distribution.  However, I think you would be better off waiting for the new
driver (see above).  That way you can help test it on kernel 2.0.  Also,
please subscribe to hpoj-announce and hpoj-devel if you haven't already so
that you can fully participate in testing and debugging.

David

Re: [hpoj-devel] Choice of Devices

[Burkhard K. <bu...@bu...>]

Allen Barnett
> Hi All,
> 
> I'm trying to decide between an HP G85 and a G95 (which is evidently the
> same machine as the G85, except you get a JetDirect 170 with it). I
> already have a B&W PostScript laser printer connected to my parallel
> port which I am loath to give up. So, I either need to be able to
> connect the new device to a USB port or get the G95 and connect it to
> the network. I have no real need currently for a networked printer,
> however. Also in the mix: I need to run a 2.4 kernel to support some
> other hardware and there (still?) appear to be some issues with its
> parallel port support.

Allen, maybe two weeks or so ago I have published a patch against 
hpoj-0.7 that allows hpoj to run with 2.4 kernels. As for the time
being I have received only two reports on success - one from myself.

I have the impression with hpoj 0.7 on Linux 2.4 that scanning now
no longer slower than on a 2.2 system. 

I have no idea about SMP systems (I just have a one processor box
at home).

In case my patch did not make it into the mailing list archive, just 
drop me a note.

Regards, Burkhard

-- 
Burkhard Kohl			bu...@bu...

[hpoj-devel] Choice of Devices

[Allen B. <ba...@lo...>]

Hi All,

I'm trying to decide between an HP G85 and a G95 (which is evidently the
same machine as the G85, except you get a JetDirect 170 with it). I
already have a B&W PostScript laser printer connected to my parallel
port which I am loath to give up. So, I either need to be able to
connect the new device to a USB port or get the G95 and connect it to
the network. I have no real need currently for a networked printer,
however. Also in the mix: I need to run a 2.4 kernel to support some
other hardware and there (still?) appear to be some issues with its
parallel port support.

I guess my question is: Is USB connectivity for the the G series going
to happen in the next month or so, or should I go ahead and get the G95.
(Or better still, is there some way I could contribute to making this
happen?)

Many thanks,
Allen Barnett

Re: [hpoj-devel] Kernel 2.4.1 module: PATCH

[Randy J. Y. <ry...@me...>]

Truly wonderful! Works like a charm on 2.4.1(up)!

Burkhard Kohl wrote:

> Randy Jay Yarger
> 
>> Burkhard,
>> Sounds great! I don't know that I'll fare any better, but more eyes
>> never hurt.
>> 
> Find my patch attached. It is against hpoj-0.7 and compiles with
> a 2.4.0-test12 kernel. After haven't looked at it for a long time
> I found some silly bugs (introduced by myself) which prevented the 
> modules to work properly. It now works with 2.4.0-test12 on my
> box (Non-SMP). If you have a 2.4.1 kernel handy, could you please 
> test them. I have not had time to look into the newer kernel.
> 
> It resolves the following issues 
> 	- it should correct for forcibly compiling with or without SMP 
> 	  support. 
>     - it takes care of changes in the parport interfaces (e.g.: 
> 	  obsolete calls to lowlevel functions, uses parport_data_forward
> 	  and parport_data_reverse). 
> 	- it takes care of changes in the queue_task interface (i.E.
>       substitutes queue_task(..., &tq_scheduler) with schedule_task.
> 
> Burkhard

RE: [hpoj-devel] no end of trouble

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Carlos.  The vast majority of the problems you described are due to
continuing incompatibilities between the kernel-mode drivers (ieee12844 and
ieee12844pp) and SMP.  I apologize for the inconvenience, and I'm working on
a long-term solution.  If you don't mind temporarily disabling SMP in the
meantime, then it will be much more stable.  Since you said scanning works
fine, another temporary option would be to switch drivers back and forth
between lp.o (for printing through /dev/lp0) and the hpoj drivers (for
scanning).  Although this requires more effort, at least you're not wasting
an entire CPU.  :-)

David

> -----Original Message-----
> From: Carlos Puchol [mailto:cp...@ro...]
> Sent: Monday, February 12, 2001 11:19 AM
> To: hpo...@li...
> Subject: [hpoj-devel] no end of trouble
> 
> 
> hi, i keep on having trouble with ptal-printd.
> any help and ideas appreciated.
> 
> i have an hp officejet g55. scanning works quite fine.
> 
> printing and ptal-printd is another matter.
> first it crashes every so often and have to restart it by hand,
> thus it seems that it needs a loop around it (to
> be a real daemon :-). or run from inetd or something.
> 
> second, about 1/2 of the time,
> it seems to print, and at some point (most of
> the time 3/4ths down the first page), it prints one line
> of garbage.
> 
> i have had it crashed like this:
> 
> # ptal-printd mlc:mlcpp0 -like /dev/lp0 &
> ptalMlcChannelOpen(chan=0x0804AE00): error connecting socket!
> ptalChannelOpen(chan=0x0804AE00): provider failed open!
> ptal-printd: ptalChannelOpen failed!
> 
> [1]+  Exit 1                  ptal-printd mlc:mlcpp0 -like /dev/lp0
> 
> 
> other times, it is printing a few pages and it halts. the display
> on the printer says "please re-connect to pc and press enter" (or
> something similar to that effect). after pressing enter, the
> printout is gone from the queue and nothing is printing any more.
> 
> also, i think it is not matching lpd. sometimes they get out of
> sync and i have to stop lpd, then start ptald, then restart lpd.
> 
> just now, i had to reboot altogether to get
> things to even print again. maybe this was a
> problem with the modules? or perhaps i am doing something wrong...
> 
> i have a redhat 6.2 system:
> 
> Linux abc 2.2.16-3smp #1 SMP Mon Jun 19 19:00:35 EDT 2000 i686 unknown
> 
> any ideas appreciated.
> 
> btw, i think the new way to run things without the wrapfilter 
> is great.
> much easier. also, the redhat srpm would be helpful too.
> 
> thanks,
> 
> -c
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel
> 

Re: [hpoj-devel] G95 All-In-One

[<pa...@rc...>]

Judd Montgomery wrote:
> I am thinking about buying a HP G95.
> This printer has network support built in.
> Will I be able to use it on the network, or does it require a Server
> also?  It looks like SANE will only connect to it from the ECP port.
> 
> Will I be able to scan from/to a PC on the network, or just the one its
> connected to?

Hi, Judd.  The G95 comes bundled with a JetDirect 170X, which plugs into
the parallel port on the OfficeJet and to a 10BaseT LAN.  In this case,
you access the G95 via the LAN on multiple PCs, rather than connecting
directly to a single PC.  This configuration is fully supported by SANE
in conjunction with the hpoj package.

See also:
http://panda.mostang.com/sane/sane-backends.html
http://www.mostang.com/sane/man/sane-hp.5.html

I hope this helps.

David

[hpoj-devel] G95 All-In-One

[Judd M. <ju...@jp...>]

I am thinking about buying a HP G95.
This printer has network support built in.
Will I be able to use it on the network, or does it require a Server
also?  It looks like SANE will only connect to it from the ECP port.

Will I be able to scan from/to a PC on the network, or just the one its
connected to?

Re: [hpoj-devel] Kernel 2.4.1 module: PATCH

[Burkhard K. <bu...@bu...>]

Randy Jay Yarger
> Burkhard,
> Sounds great! I don't know that I'll fare any better, but more eyes
> never hurt.
> 
Find my patch attached. It is against hpoj-0.7 and compiles with
a 2.4.0-test12 kernel. After haven't looked at it for a long time
I found some silly bugs (introduced by myself) which prevented the 
modules to work properly. It now works with 2.4.0-test12 on my
box (Non-SMP). If you have a 2.4.1 kernel handy, could you please 
test them. I have not had time to look into the newer kernel.

It resolves the following issues 
	- it should correct for forcibly compiling with or without SMP 
	  support. 
    - it takes care of changes in the parport interfaces (e.g.: 
	  obsolete calls to lowlevel functions, uses parport_data_forward
	  and parport_data_reverse). 
	- it takes care of changes in the queue_task interface (i.E.
      substitutes queue_task(..., &tq_scheduler) with schedule_task.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] OJ 700 Progress

[Robert G. B. <rg...@ph...>]

On Tue, 13 Feb 2001, Gerhard Fuernkranz wrote:

> David Paschal wrote:
> >
> > James Klicman wrote:
> > > I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION
> > > and then creating a viewable .pgm file with the data.
>
> A very simple, easy graphics file format.
> Actually it is a whole family consisting of
>
> "pbm" -> bitmap with depth=1, each pixel can be
>          black/white (-> e.g. a typical Fax)
> "pgm" -> a grayscale picture
> "ppm" -> a RGB color picture (truecolor with RGB
>          for each pixel, not with colormap/indexed
>          like a GIF)
> "pnm" -> used to denote the family, i.e. any of
>          the above three
>
> There also exist the pbmplus tools for manipulating
> these file types, see /usr/X11R6/bin/*{pbm,pgm,ppm,pnm}*
>
> Gerhard

Indeed, a lot of those tools are already in place and automatically used
in the printer filters, at least for a RH system.  Once you get it into
a p?m format, you have a number of tools for scaling, rotating, and the
like.  RH's strategy appears to be "get an arbitrary format into pnm,
then convert pnm to ps, then print (usually using ghostscript printer
filters)."  See:

rgb@ganesh|T:120>dir /usr/lib/rhs/rhs-printfilters/
bmp-to-pnm.fpi*  gif-to-pnm.fpi*  pnm-to-ps.fpi*   tiff-to-pnm.fpi*
dvi-to-ps.fpi*   jpeg-to-pnm.fpi* rast-to-pnm.fpi* troff-to-ps.fpi*

where in these filters many of the tools are demonstrated in pipes.

A single example.  If you have a digital camera and take a lot of
pictures, you probably want to turn the hi-res jpegs into low-res,
rescaled, possibly rotated gifs to stick up on your website.  Here is a
fragment from a little perl script I wrote to help me make this
conversion:

 $command = "cat $INFILE | djpeg -pnm | pnmscale $scale | pnmrotate $rotate | ppmquant 256 | ppmtogif - > $OUTFILE";
 if($verbose){ print "$command\n"; }
 system($command);

djpeg converts jpeg to pnm (among others -- it will convert straight to
gif but not allow scaling and rotation).  pnmscale and pnmrotate scale
and rotate the "pixel any map" (pnm). ppmquant fixes the colormap depth
-- useful if you don't want to exhaust the colormap of a low-res 8 bit
display on an unknown browser somewhere.  Finally ppmtogif does the
final conversion to gif.  Using a tool like this (with obvious perl
wrapping it and setting the variables, full program available on
request) allows one to convert a whole directory of jpegs with a simple
shell loop, and is often a lot easier and faster to use than cranking up
a whole GUI (e.g. xv or eeyes or gimp or whatever) just to do a simple
rotation and scaling.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...

Re: [hpoj-devel] OJ 700 Progress

[Gerhard F. <ger...@fu...>]

David Paschal wrote:
> 
> James Klicman wrote:
> > I have succeeded in scanning BILEVEL_THRESHOLD/NO_COMPRESSION
> > and then creating a viewable .pgm file with the data.

A very simple, easy graphics file format.
Actually it is a whole family consisting of

"pbm" -> bitmap with depth=1, each pixel can be
         black/white (-> e.g. a typical Fax)
"pgm" -> a grayscale picture
"ppm" -> a RGB color picture (truecolor with RGB
         for each pixel, not with colormap/indexed
         like a GIF)
"pnm" -> used to denote the family, i.e. any of
         the above three

There also exist the pbmplus tools for manipulating
these file types, see /usr/X11R6/bin/*{pbm,pgm,ppm,pnm}*

Gerhard

[hpoj-devel] no end of trouble

[Carlos P. <cp...@ro...>]

hi, i keep on having trouble with ptal-printd.
any help and ideas appreciated.

i have an hp officejet g55. scanning works quite fine.

printing and ptal-printd is another matter.
first it crashes every so often and have to restart it by hand,
thus it seems that it needs a loop around it (to
be a real daemon :-). or run from inetd or something.

second, about 1/2 of the time,
it seems to print, and at some point (most of
the time 3/4ths down the first page), it prints one line
of garbage.

i have had it crashed like this:

# ptal-printd mlc:mlcpp0 -like /dev/lp0 &
ptalMlcChannelOpen(chan=0x0804AE00): error connecting socket!
ptalChannelOpen(chan=0x0804AE00): provider failed open!
ptal-printd: ptalChannelOpen failed!

[1]+  Exit 1                  ptal-printd mlc:mlcpp0 -like /dev/lp0


other times, it is printing a few pages and it halts. the display
on the printer says "please re-connect to pc and press enter" (or
something similar to that effect). after pressing enter, the
printout is gone from the queue and nothing is printing any more.

also, i think it is not matching lpd. sometimes they get out of
sync and i have to stop lpd, then start ptald, then restart lpd.

just now, i had to reboot altogether to get
things to even print again. maybe this was a
problem with the modules? or perhaps i am doing something wrong...

i have a redhat 6.2 system:

Linux abc 2.2.16-3smp #1 SMP Mon Jun 19 19:00:35 EDT 2000 i686 unknown

any ideas appreciated.

btw, i think the new way to run things without the wrapfilter is great.
much easier. also, the redhat srpm would be helpful too.

thanks,

-c

Re: [hpoj-devel] Kernel 2.4.1 module

[Randy J. Y. <ry...@me...>]

Burkhard,
Sounds great! I don't know that I'll fare any better, but more eyes
never hurt.

Thanks!
Randy
-- 
Randy Jay Yarger
ry...@me...

On 12 Feb 2001 13:23:05 +0100, Burkhard Kohl wrote:
> Randy Jay Yarger
> > Greetings,
> > 
> > I'm wondering if anyone is currently working out the 2.4.x kernel
> > issues?
> > If not, I may take a crack at it myself. Now that the kernel is
> > officially released
> > people are going to start migrating in large numbers...
> 
> As David already wrote I was it me trying to look into it but I 
> gave up - I was unable to resolve the timing issues. If you are
> interested I can send you my latest (non-working) patch and comment
> on my findings.
> 
> Burkhard
> -- 
> Burkhard Kohl                 bu...@bu...
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/lists/listinfo/hpoj-devel