Re: Printing as an example: has embrace and extend accomplished it's objectives?

[Rick Moen <rick@linuxmafia.com>]

Alan, it would be excellent to be able to assist you.  (And, yes, I
think everyone did understand that your upthread post wasn't itself a
support request.)  So:

Quoting Alan Davis (alan3davis@gmail.com):

> Here's my problem, in a nutshell: When I print many pages, more than, maybe
> 15, on my new(er) Epson printer, the job is interrupted, a few lines of
> fading text are printed, and t the job restarts automatically from the
> beginnng.  This printer defaults to Reverse page ordering, so it starts
> again on the last page.  This always happens, so, if I am not paying close
> attention, I was come back to see the output tray deep in pages, and the
> printer still working.  

Distressing, indeed.  Would you mind please posting back with the
specific Epson model?  Also, over what connection interface do print
jobs reach the printer, e.g., wireless networking, USB, wired ethernet? 
That information (answers to both questions) often proves essential.

While I'm waiting for you to get back to us on that:

1.  I like (as in applaud) your way of thinking, that attempting to
narrow down whether it's software or hardware-based is a promising
approach.  But before we can do much of that, we'll need the specific
printer model, because Epson printers differ very widely in their
printing technology implmentations.  For example, some printers made by
Epson (and by some other manufactureres) are deliberately incomplete as
to the integral hardware, omitting the RAM and processor to build and
buffer a page raster.  Instead, the user is prompted to install a piece
of proprietary software on the attached host PC, that serves as an
outboard 'print engine' for the printer, building the page raster in PC
RAM and then spooling it out over the PC's printing facility (e.g.,
CUPS) to the printer.  (Generically, these are called 'GDI' printers:
As you can probably tell, I have a low opinion of that specific design
and always urge strenuously avoidance.)

Other printers take a variety of more-conventional approaches, and the
point is that debugging problems is a different proposition depending on
how the thing does printing.

2.  Live distros[1] are often really useful for doing a comparative test, 
because the test run then sidesteps your installed Manjaro system's
software.  If the problem _doesn't_ replicate with the live distro, 
then you can have high confidence you've isolated the cause to some
problem in your Manjaro installation.  If on the other hand the problem
persists when running the live distro, then you have not yet narrowed
down the cause.

3.  Any chance you can cross-check by printing to the printer from some
other computer entirely?  Again, this helps isolate cause:  If the
problem reproduces with different computers and OSes, then you can have
high confidence that you've isolated the cause to the printer itself
(and, I suppose, it's access cable or network mechanism).

4.  If the printer happens to support multiple access methods (e.g.,
wireless networking, USB, wired ethernet), does the problem replicate if
you switch to one of the others?  Again, this is using logic and
comparative data, making exactly one change and carefully not
introducing any other variables and then doing the same test print, 
to isolate the root cause.

As an aside to that, I've seen in lots of years of reading that printing
straight to printers over WiFi (a feature mostly offered in inkjets) has
_tons_ of problems.

And I should distinguish, here:  The laptop I'm typing on reaches
everything else without exception including the house's Lexmark E250dn
laser printer over WiFi, but that's not what I'm talking about.

our Lexmark printer is connected over wired ethernet (from the Lexmark's
RJ-45 ethernet port) to a wireless access point (WAP).  The WAP bridges
that traffic to the wireless network segment serving my laptop and other
household computing devices.  By contrast, what I'm talking about are
printers reached _directly_ over Wifi.  That has for some years been a
recipe for trouble, largely because it entails dodgy and proprietary
non-standard software layers to carry the printing traffic.


> To test theory #1, in part, I intend to configure this printer to print in
> "normal" page order.  Apparently this has been problematic for some others,
> as I have seen some lengthy instructions on how to set the options.   Any
> of these?
> 
>    - using the gui doesn't show these kinds of options
>    - using lpoptions, or lpadmn---which interesting do things differently
>    - MAYBE editing the ppd file.  However, as it turns out there are
>    multiple copies on the system, including one sequestered by CUPS.
>  - Printing from the command line with options

I am unclear on what specifcally you are referring to, when you say 'the
GUI'.

Usually with printers -- and, again, we unfortunately have no idea what
printer you have, except that it's an Epson -- there is some means to
configure them via front-panel controls or some similar mechanism.  You
should find details in the user manual, which if you don't have one can
(and should) be found online via search engine.

Usually, the printer's built-in administrative interface, however it is
reached, has other functions such as making the printer conduct a
diagnostic self-test and making it print out a test page and often one
displaying all of its current settings.  I would encourage you to
explore that.

I doubt that you should go around editing PPD files.  For one thing,
I've never heard of a printer problem best addressed by local PPD
hackery.  For another, you risk introducing yet more uncontrolled
variables into the test environment, which is the exact opposite of what
you should be aiming to do.



[1] I haven't done much playing around with live distros in years, so much
knowledge is rusty.  When I last did, I was fond of Siduction, because 
it used very cutting-edge versions of constituent application and system
software, and was released every quarter.  This is very helpful if
someone has done the masochistic thing and just bought a spanking-new
model of something that thus needs cutting-edge driver software (if a
driver yet exists at all).

One thing I remember about Siduction:  They shared the somewhat cranky
stance of their Aptosid forebears (having been a fork of Aptosid) that
the distro shall not bundle proprietary drivers in the ISO, so
retrofitting such drivers into the runtime system, where necessitated by
poor hardware selection, becomes an additional slog.

Hmm, as often happens with these projects, their release schedule has
been slacking off more and more:
https://distrowatch.com/table.php?distribution=siduction
At this date, the last ISO release (in eight Desktop Environment
flavours!) was well over a year ago.

The ideal live distro would be one with frequent ISO releases, a
cutting-edge focus and a 'rolling' model generally, and inclusion of
proprietary driver junk to the extent permitted by law.
A Distrowatch search brings up this list of candidates:
https://distrowatch.com/search.php?ostype=Linux&category=Live+Medium&origin=All&basedon=All&notbasedon=None&desktop=All&architecture=All&package=All&rolling=Rolling&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simple





Over and over.  This problem could be hardware or
> software.  I have two or three theories:
> 
>    1. Memory.  Some kind of memory must be involved i printing a job in
>    reverse order.  Perhaps memory for this purpose has been exhausted.   The
>    Fax component has sufficient memory for 100 pages; the nature or amount of
>    printer memory is unknown.  This theory may be supported by the fact that
>    each time a document restarts, it is at a SIMILAR, but not identical place
>    and page.
>    2. Wifi glitches.  Perhaps the wifi burps, the job is interrupted, and
>    falls of the deep end.


> This should be simple, right?  Specify the pages to be printed in "normal"
> (as opposed to "reverse") order.
> 
> I have attempted twice to post to Manjaro's forum.
> 
> I take the advice seriously, to do diligence when asking for advice.  I can
> often fix a problem, given time.  Ironically, some times the solution
> suggests itself to me after I have posted a help request!  Often.
> 
> Thank you for the kindness of responding to my post.   I don't suppose I
> have clarified much in this one.
> 
> Alan Davis
> 
> On Mon, Sep 2, 2019 at 3:02 AM Rick Moen <rick@linuxmafia.com> wrote:
> 
> > Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
> >
> > > Well, I was inclined to say ... and still relevant, ...
> > > file good bug report(s).
> > >
> > > Rick addressed many of the relevant points, bug good bug reports,
> > > or even more generally, providing the relevant technical information
> > > about the issue to the appropriate "forum" or the like is quite useful.
> >
> > /me bows.
> >
> >
> > I should elaborate briefly on a passage in my upthread post:
> >
> >   You might, e.g., need a specific print filter set you haven't
> >   bothered to install, or you might be missing some maddening
> >   proprietary junk like an HPLIP proprietary plug-in.
> >
> > Many people are unware that CUPS is a printing engine aka framework
> > that, as often packaged in Linux distributions, comes with a quite
> > limited set of 'filters' (aka 'drivers') for specific printer types.
> > So, in many cases, all you really need to do, to accomodate a
> > particularly problematic printer, is to install an optional Linux
> > software package furnishing the relevant driver set.
> >
> > What Linux Foundation did to Grant Taylor's storied LinuxPrinting.org,
> > in turning it into the much-lesser Linux Foundation sub-site
> > 'OpenPrinting', is IMO somewhere between regrettable and unspeakable,
> > _but_ the entries at OpenPrinting about recommended filters [/drivers]
> > for particular printer models remains indispensible -- IMO -- and ought
> > to be one's first stop.
> >
> > 'HPLIP', the filter (driver) set from Hewlett-Packard for its printers
> > and scanners, has an undeserved reputation as meritorious open source,
> > when in truth, HP have consigned to secret-sauce HPLIP 'plugin'
> > proprietary software the necessary code to run many of their printers
> > and scanners.  And those plugins are _not_ distributed inside the CUPS
> > packages of Linux distributions --- because they're proprietary crud.
> >
> > Anyway, if a printer is usable under CUPS on any OS including Apple OS
> > X, then is usable under CUPS on Linux using the same techniques, because
> > CUPS is CUPS.  It's genuine open source under the APSL licence.
> >
> > Anyway, if the OP is serious about getting substantive help, he should
> > finally get around to providing specifics.  Otherwise, he is just
> > venting rhetoric (e.g, this 'embrace and extend' bushwah), and that is a
> > waste of time, frankly.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "BerkeleyLUG" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to berkeleylug+unsubscribe@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/berkeleylug/20190902100152.GV24339%40linuxmafia.com
> > .
> >
> 
> 
> -- 
>  I consider that the Golden Rule requires that if I like a program I must
> share it with other people who like it.
>               --- Richard Stallman
> 
> "As we enjoy great advantages from the inventions of others, we should be
> glad of an opportunity to serve others by any invention of ours."
> 
>        ---Benjamin Franklin
> 
> -- 
> You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/CAF%2BxKT5s-0ej%3D-Dyo8PqyPTXVyn28-cVfa1SspAcQ2UXdrTx-A%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20190902213916.GX24339%40linuxmafia.com.