Home » Archived » BIRT » UNIX printing
|
| Re: UNIX printing [message #1706 is a reply to message #1697] |
Mon, 10 January 2005 10:38   |
Eclipse User |
|
|
|
Originally posted by: ferrisoxide.gmail.com
In article <crovr1$7b9$1@www.eclipse.org>,
"Sven Boden" <svenboden@hotmail.com> wrote:
> Would BIRT support printing on UNIX on non-postscript printers?
>
> For example when BIRT would be integrated with an assembly line application
> deployed on UNIX (granted it's not really business intelligence, but it's
> also reporting). Most of the big manufacturing printers can be turned into
> network printers, but most of them do not support PDF: Printronix,
> Mannesmann, ...
>
> A few problems for this kind of situation:
> 1) The printer escapes will somehow have to be generated (no Windows printer
> drivers on UNIX), so this would require some kind of own "printer-driver"
> framework where escapes can be added per printer type.
> 2) For most assembly lines guaranteed delivery of manifests is critical so
> this would need some kind of active protocol towards the printer: instead of
> putting the report output in a queue somewhere it would require
> communicating with the printer until the manifest is successfully printed.
> 3) It's possible the printer does not support 'free-form' on pixel level but
> e.g. only on 'line level', e.g. text may only begin at certain vertical
> offsets. Which may have a manifest look a little bit diferent than in the
> designer.
>
> Regards,
> Sven Boden
Hi Sven
I don't know the answer, though I admire the problem. :)
Out of interest, do you have a specific application that relates to
manufacturing? I ask because I'm very interested in the application of
business intelligence to manufacturing.
Given the nature of the problem, and the importance of being able to
produce accurate manifests, batch reports, etc, I suspect that you will
need a different mechanism for producing reports. Maybe BIRT isn't the
right tool in this instance. I could be incorrect here, but aren't many
of these sorts of reports done in real-time, and printed often on a
line-by-line basis as events occur in the production line? BIRT seems
more predicated on producing reliable information on historical
information (i.e. data stored in databases).
Cheers
Tom
|
|
|
| Re: UNIX printing [message #2753 is a reply to message #1697] |
Mon, 10 January 2005 22:53 |
 Stanley Wang
Messages: 81
Registered: July 2009 |
Member |
|
|
Sven,
The first release of BIRT will only support printing in PDF format.
However, postscript printing on Unix could be added in the future.
Our current thought is that almost all major printers support postscript
or PDF. Even if a printer is claimed to be a PCL printer, the vendor often
provides a downloadable postscript driver file. If a postscript printing
system is to be implemented for BIRT, the postscript file will likely be
generated in the following way: (1) the printer driver is parsed and
printer specific commands (i.e., printer escapes) are generated for
printer-specific features, such as collation, paper tray, landscape vs.
portrait, etc. (2). report contents, which are usually drawn in a
printer-independent way, are generated as printer-independent postscript.
The active protocol for talking to printer to confirm print status is
another component that could be implemented in BIRT, but it is likely to
come only after postscript printing is supported. On the other hand, can
you use third-party tools to monitor the printing progress?
We have not planned anything in the area of printing to non-postscript
printers on Unix. Actually, we are not sure if it is necessary, and your
experience may help us come up with a sound usage scenario. Do you know
printers that would absolutely not support postscript? Can you give some
examples (manufacturer and model)?
I am not an expert on assembly line application, so I can not imagine how
the reports in such an area look like. Is Toms comment that reports are
done in real-time, and printed often on a line-by-line basis as events
occur in the production line accurately described what your need?
Scripting may help you address advanced needs. I may be able to make more
specific comments if you can let me know a real example from such
applications.
Thanks. --Stanley
Stanley Wang
Actuate Corp.
BIRT project lead
Sven Boden wrote:
> Would BIRT support printing on UNIX on non-postscript printers?
> For example when BIRT would be integrated with an assembly line application
> deployed on UNIX (granted it's not really business intelligence, but it's
> also reporting). Most of the big manufacturing printers can be turned into
> network printers, but most of them do not support PDF: Printronix,
> Mannesmann, ...
> A few problems for this kind of situation:
> 1) The printer escapes will somehow have to be generated (no Windows printer
> drivers on UNIX), so this would require some kind of own "printer-driver"
> framework where escapes can be added per printer type.
> 2) For most assembly lines guaranteed delivery of manifests is critical so
> this would need some kind of active protocol towards the printer: instead of
> putting the report output in a queue somewhere it would require
> communicating with the printer until the manifest is successfully printed.
> 3) It's possible the printer does not support 'free-form' on pixel level but
> e.g. only on 'line level', e.g. text may only begin at certain vertical
> offsets. Which may have a manifest look a little bit diferent than in the
> designer.
> Regards,
> Sven Boden
|
|
|
| Re: UNIX printing [message #2841 is a reply to message #1706] |
Wed, 12 January 2005 21:35 |
Sven Boden
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Tom Tuddenham wrote:
> I don't know the answer, though I admire the problem. :)
> Out of interest, do you have a specific application that relates to
> manufacturing? I ask because I'm very interested in the application of
> business intelligence to manufacturing.
> Given the nature of the problem, and the importance of being able to
> produce accurate manifests, batch reports, etc, I suspect that you will
> need a different mechanism for producing reports. Maybe BIRT isn't the
> right tool in this instance. I could be incorrect here, but aren't many
> of these sorts of reports done in real-time, and printed often on a
> line-by-line basis as events occur in the production line? BIRT seems
> more predicated on producing reliable information on historical
> information (i.e. data stored in databases).
> Cheers
> Tom
As application consider a printing system for a car assembly line. For a
list of usages:
1) very small forms which are printed for every car passing a certain
point in the plant and consist only of a single line of information, to
order mirrors e.g.
2) Bigger forms, e.g. a trim manifest... a big piece of paper attached to
the car during production that contains e.g. all options you ordered on
the car. From far it look like a big piece of paper with big squares on it
with 1 item of data printed per square (in a font of 1 to 2 inches high)
3) Analysis reports... number of cars with certain kind of scratches on
them that had to be repainted, ... Not used in the plant itself but more
by plant management
1) and 2) e.g. now consist of C applications, a "manifest editor" that
allows a user to specify a layout: data items, lines, harcoded text,
barcodes, translations, ...
The application that prints the manifests knows to which kind of printer
it prints and generates the required escape codes for non-postscript
printer, the manifests are the same for all printers (specified in "data
item x at line 4, position 5, 2 high, 2 wide", "vertical line at column 4
from line 3 to 6", ...)
Since multiple non-postscript printers are used the application has to
have a set of escapes per printer type, so it knows how to generate the
form a a particular type of printer. StreamServe, another
"broadcasting/printing" works in a similar way, generating escapes per
printer type (and per firmware version of the printer).
So for 1) and 2) it's not BI but the requirements overlap a lot... you
need print-outs for a set of data, and you have a user who wants to
maintain the layout themselves via a GUI tool.
Sven
|
|
|
| Re: UNIX printing [message #2858 is a reply to message #2753] |
Wed, 12 January 2005 22:10 |
Sven Boden
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Stanley Wang wrote:
> Sven,
> The first release of BIRT will only support printing in PDF format.
> However, postscript printing on Unix could be added in the future.
Ok
> Our current thought is that almost all major printers support postscript
> or PDF. Even if a printer is claimed to be a PCL printer, the vendor often
> provides a downloadable postscript driver file. If a postscript printing
> system is to be implemented for BIRT, the postscript file will likely be
> generated in the following way: (1) the printer driver is parsed and
> printer specific commands (i.e., printer escapes) are generated for
> printer-specific features, such as collation, paper tray, landscape vs.
> portrait, etc. (2). report contents, which are usually drawn in a
> printer-independent way, are generated as printer-independent postscript.
> The active protocol for talking to printer to confirm print status is
> another component that could be implemented in BIRT, but it is likely to
> come only after postscript printing is supported. On the other hand, can
> you use third-party tools to monitor the printing progress?
If you want to be absolutely sure the form is on the printer, something as
HP OpenView will not help 100%, it may inform you of printer problems but
during that time you may already have lost reports.
> We have not planned anything in the area of printing to non-postscript
> printers on Unix. Actually, we are not sure if it is necessary, and your
> experience may help us come up with a sound usage scenario. Do you know
> printers that would absolutely not support postscript? Can you give some
> examples (manufacturer and model)?
There are still a lot of printers out there without any postscript
support:
- Larger models of printronix (which using IGP printing language:
http://www.printronix.com/multinational/emea_eng/ and search for IGP), e.g
the printronix L1524
- Larger Models of Mannesmann Tally, e.g. T6212. which uses MAGNUM escape
codes.
- All Zebra printers. e.g.
http://www.zebra.com/PA/Printers/product_R170Xi_hs.htm
Most of these have printer drivers for windows which probably convert
application printing transparantly to their own escapes, but on UNIX
you're mostly on your own since UNIX has no real printer drivers.
> I am not an expert on assembly line application, so I can not imagine how
> the reports in such an area look like. Is Tom?s comment that reports are
> ?done in real-time, and printed often on a line-by-line basis as events
> occur in the production line? accurately described what your need?
> Scripting may help you address advanced needs. I may be able to make more
> specific comments if you can let me know a real example from such
> applications.
Currently reports used in an assembly line can look like whatever the user
wants to put on the report. The user can edit reports and add barcodes,
lines, hardcoded texts, database fields, ... on a report. The report
definition is stored, and at some point in time when a car passing a
certain point in the plant the data for the car is fetched from the
database, the report is filled and printed (and checked whether the
printout really succeeds). Reports can be anything from 2 cm high and 30
cm wide to full blown A2 size reports (printing e.g. in 2 inch high font
for visibility).
Besides the actual printing a plant can also contain big (touch) screens
on which data is shown on the car which passes that location, so data is
pushed to the screen.
The Unix version of StreamServe (http://www.streamserve.com) to name just
1 other product also prints to non-postscript printers by generating
printer escapes.
Regards,
Sven
|
|
|
| Re: UNIX printing [message #2894 is a reply to message #2858] |
Thu, 13 January 2005 19:39 |
Sven Boden
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Maybe to give some more explanation what I had in mind and what is
currently used in at least 1 manufacturing application (but I don't think
it's that
far away from BIRT functionality) ;-)
- A user designs reports. Elements:
- fields from a database
- array fields (also fetched from a database:
all elements of the same size)
- barcodes: mostly code 39
- horizontal and vertical lines
- hardcoded text
- argument text (text given when a print-out is requested)
- calculated fields (based on any other fields):
- subtotals
- totals
- some kind of logical processing (if a field matches
"AAA" print "YES' else "NO")
- Print Time/Date
- ...
The user enters the elements as e.g. "hardcoded text, 2 high, 2 wide,
text = "EXAMPLE", column 2, row 5". All elements have a bounded border
in which the element may draw itself (the column, row definition is the
top, left corner of an element).
- The application triggering the print-outs uses 2 ways of requesting
it.
- Single reports: a report definition together with a "primary" key
is sent to the application meaning "print the report for this key"
- List of reports: an ordered set of report definitions with their
corresponding primary keys are sent to the application.
The list were required to get "transactions" in reports (a list succeeds
to be printed if all reports in the list are printed) and to be able
to print off more than 1 report on a single page (e.g. PCL printers
throw out the paper when you issue the "print" command). A list of
reports
can be used to make something as: "a header, followed by a number of
small detail reports, followed by a footer).
- The printing application is build up of multiple sub-modules:
- Open the report, parse the definition into memory DesignElements
- Get the data out of a DataSource and attach the data to the
DesignElements. For some items multiple passes are required to fill
in the data like subtotals, totals, ...
- Then the whole lot is passed to a kind of "Printing module", a
printing
module consists of a "formatting module" and a "protocol module".
The formatting module is a pluggable architecture, the printing
application is set up with the type of printer and the firmware
version
of the printer.
The list of design elements is sorted from top left corner to bottom
right corner in a zig-zag format. If overlapping objects are allowed
the objects that overlap should be in the right order as well,
objects
in front of an overlapping appearing later in the list), some
plugins
reorder the list themselves.
Depending on the type of printer a plug-in is defined that generates
the required escapes in the header, before and after each data
element,
and the footer + new page instructions.
The logic in the plug-ins is that they should do a best-effort to
get the output to look like in the designer, but if pixel perfection
is not possible they should stay in the bounding border of the
element.
The end result of this is a set of printer escapes for a type of
printer, the protocol module then takes these escapes and prints
them to a printer using a specified active or passive protocol.
Trying to apply it to BIRT as a thought excercise, a pluggable module
would consist first of outputting the PDF format while other formats could
be added later on as extra objects. If plug-ins are shared BIRT could
print on almost any printer in the world. Html plugins, SVG, ... would be
very easy to achieve as well.
Regards,
Sven Boden
|
|
|
| Re: UNIX printing [message #4427 is a reply to message #2894] |
Wed, 19 January 2005 19:21 |
Stanley Wang
Messages: 81
Registered: July 2009 |
Member |
|
|
Sven,
Thanks for the detailed description of how a manufacturering reporting
application looks like. As you have suggested, the report design and
rendering flow there is not much different from BIRT's assumptions.
BIRT is designed to allow seamless extensions. So your formatting and
protocol modules can be designed as plugins.
I have included more comments inline.
Thanks. --Stanley
Stanley Wang
Actuate Corp.
BIRT project lead
Sven Boden wrote:
> Maybe to give some more explanation what I had in mind and what is
> currently used in at least 1 manufacturing application (but I don't think
> it's that
> far away from BIRT functionality) ;-)
> - A user designs reports. Elements:
> - fields from a database
> - array fields (also fetched from a database:
> all elements of the same size)
[Stanley] What is exactly an array field? I think BIRT should be able to
process it; even if not, you should be able to easily write a dataset
extension to handle this as all fields are of the same size.
> - barcodes: mostly code 39
[Stanley] Are they images, or barcode font characters? Images will be
handled naturally. Bar code font may be made to work using some
configurations. If the report is to be viewed in a browser, it may just
work as long as the bar code font exists on the client machine.
> - horizontal and vertical lines
[Stanley] BIRT R1 does not support lines, but they will be added in
following releases. It may also be easy to add it (through customization)
as an extended item to R1.
> - hardcoded text
> - argument text (text given when a print-out is requested)
> - calculated fields (based on any other fields):
> - subtotals
> - totals
> - some kind of logical processing (if a field matches
> "AAA" print "YES' else "NO")
> - Print Time/Date
> - ...
[Stanley] All these are handled naturally. The conditional logic is
handled through highlight rules.
> The user enters the elements as e.g. "hardcoded text, 2 high, 2 wide,
> text = "EXAMPLE", column 2, row 5". All elements have a bounded border
> in which the element may draw itself (the column, row definition is the
> top, left corner of an element).
[Stanley] What does the 2 high and 2 wide mean? Do they define the size of
a box? If the content in the box exceeds the box size, do we truncate or
overlap? What does column and row mean? Does it mean that the page is
pre-divided into well-defined grids?
> - The application triggering the print-outs uses 2 ways of requesting
> it.
> - Single reports: a report definition together with a "primary" key
> is sent to the application meaning "print the report for this key"
> - List of reports: an ordered set of report definitions with their
> corresponding primary keys are sent to the application.
> The list were required to get "transactions" in reports (a list succeeds
> to be printed if all reports in the list are printed) and to be able
> to print off more than 1 report on a single page (e.g. PCL printers
> throw out the paper when you issue the "print" command). A list of
> reports
> can be used to make something as: "a header, followed by a number of
> small detail reports, followed by a footer).
[Stanley] I suspect your requirement could be fulfilled by report
parameters. Depending on the parameters passed in, different portions of
the report can be printed. I am not quite sure what print off more than 1
report on a single page mean. It may be implemented by a parallel report,
where two streams of report contents can be put together shoulder by
shoulder. A subreport may also help. I am fairly confident that your
requirements could be fulfilled in R1, and the remaining issue is how easy
or how hard. The ROM Layout spec would give you more ideas and allows you
to make a better judgement.
> - The printing application is build up of multiple sub-modules:
> - Open the report, parse the definition into memory DesignElements
> - Get the data out of a DataSource and attach the data to the
> DesignElements. For some items multiple passes are required to fill
> in the data like subtotals, totals, ...
[Stanley] This is similar to BIRT model.
> - Then the whole lot is passed to a kind of "Printing module", a
> printing
> module consists of a "formatting module" and a "protocol module".
> The formatting module is a pluggable architecture, the printing
> application is set up with the type of printer and the firmware
> version
> of the printer.
[Stanley] The formatting module is what BIRT will provide now. The
protocol module may take a while to be added into BIRT. If you find the
formatting module in BIRT is not adequate, you can always enhance it or
even plug in your own.
> The list of design elements is sorted from top left corner to bottom
> right corner in a zig-zag format. If overlapping objects are allowed
> the objects that overlap should be in the right order as well,
> objects
> in front of an overlapping appearing later in the list), some
> plugins
> reorder the list themselves.
[Stanley] This sounds like that all elements have exact positioning (i.e.
top left corner coordinate is fixed), right? Is the overlap handling
dynamic or static, i.e., it is by design, or it depends on the data? If it
is by design, a z-order built into the design could address it. If it is
dynamic, BIRT currently does not support this type of logic (as it is too
specialized). However, you may write your own extended element as BIRT
intends to support excellent extension. I assume when you mention zig-zag
format, you mean printing to a printer without page-buffer. If so, that is
another excellent example for extension. Postscript, on the other hand,
allows you to place contents out-of-order but still print them correctly (
mean the printer still prints the content in zig-zag fashion, but the
printing command does not need to be issues in the same order).
> Depending on the type of printer a plug-in is defined that generates
> the required escapes in the header, before and after each data
> element,
> and the footer + new page instructions.
> The logic in the plug-ins is that they should do a best-effort to
> get the output to look like in the designer, but if pixel perfection
> is not possible they should stay in the bounding border of the
> element.
> The end result of this is a set of printer escapes for a type of
> printer,
[Stanley] Yes, BIRT engine is structured this way so that you can write
your own plug-in to generate escapes. PDF and HTML are just two formats we
write, and the others are free to implement their own plug-in. BIRT
provides an interface with functions such as onRow, onCell, etc. so that
you can implement your printing logic.
> the protocol module then takes these escapes and prints
> them to a printer using a specified active or passive protocol.
> Trying to apply it to BIRT as a thought excercise, a pluggable module
> would consist first of outputting the PDF format while other formats could
> be added later on as extra objects. If plug-ins are shared BIRT could
> print on almost any printer in the world. Html plugins, SVG, ... would be
> very easy to achieve as well.
[Stanley] Agreed. In particular, if you already have code to generate the
printer escape, what it takes is likely an adapter that implements BIRTs
extension interface.
> Regards,
> Sven Boden
|
|
|
| Re: UNIX printing [message #4500 is a reply to message #4427] |
Thu, 20 January 2005 22:54 |
Sven Boden
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Been thinking some more on the extension principle... Won't BIRT always have
a "problem" with it:
You can extend with components, but you can also extend output types. The
logic for output generation either needs to be in the components or in some
object of the output type (in BIRT I would guess it's in the components).
Doesn't the work for extensions then grow extensively with a lot of
component extensions or with a lot of output types, if all components should
be supported on all output types. Or extensions should only use a
composition of existing components.
Some more comments inline ;-)
Regards,
Sven Boden
"Stanley Wang" <swang@actuate.com> wrote in message
news:csmbug$ocv$1@www.eclipse.org...
> Sven,
>
> Thanks for the detailed description of how a manufacturering reporting
> application looks like. As you have suggested, the report design and
> rendering flow there is not much different from BIRT's assumptions.
>
> BIRT is designed to allow seamless extensions. So your formatting and
> protocol modules can be designed as plugins.
>
> I have included more comments inline.
>
> Thanks. --Stanley
>
> Stanley Wang
> Actuate Corp.
> BIRT project lead
>
>
> Sven Boden wrote:
>
>
> > Maybe to give some more explanation what I had in mind and what is
> > currently used in at least 1 manufacturing application (but I don't
think
> > it's that
> > far away from BIRT functionality) ;-)
>
> > - A user designs reports. Elements:
> > - fields from a database
> > - array fields (also fetched from a database:
> > all elements of the same size)
>
> [Stanley] What is exactly an array field? I think BIRT should be able to
> process it; even if not, you should be able to easily write a dataset
> extension to handle this as all fields are of the same size.
[Sven] An array field in "my" context is a set of fields of the same size
that may get wrapped per x elements with a number of spaces between each
element and a number of lines between each line. E.g.
XXXX XXXX XXXX XXXX
XXXX XXXX
Would be something an array of 4 elements per line, no interlining and 2
spaces between each element. You can specify a minimum number of elements
for which space is allocated. It's used to print all options pf a vehicle
e.g. (one after the other).
>
> > - barcodes: mostly code 39
>
> [Stanley] Are they images, or barcode font characters? Images will be
> handled naturally. Bar code font may be made to work using some
> configurations. If the report is to be viewed in a browser, it may just
> work as long as the bar code font exists on the client machine.
[Sven] Depending on the printer, printronix has special escapes to do
barcoding, HP-PCL printers will receive a series of a line command (if no
barcode module is present). A lot of application use barcodes.
>
> > - horizontal and vertical lines
>
> [Stanley] BIRT R1 does not support lines, but they will be added in
> following releases. It may also be easy to add it (through customization)
> as an extended item to R1.
[Sven] As at the top of the mail, don't you fear a little bit a possible
"wild growth" extensions?
>
> > - hardcoded text
> > - argument text (text given when a print-out is requested)
> > - calculated fields (based on any other fields):
> > - subtotals
> > - totals
> > - some kind of logical processing (if a field matches
> > "AAA" print "YES' else "NO")
> > - Print Time/Date
> > - ...
>
> [Stanley] All these are handled naturally. The conditional logic is
> handled through highlight rules.
>
> > The user enters the elements as e.g. "hardcoded text, 2 high, 2 wide,
> > text = "EXAMPLE", column 2, row 5". All elements have a bounded border
> > in which the element may draw itself (the column, row definition is
the
> > top, left corner of an element).
>
> [Stanley] What does the 2 high and 2 wide mean? Do they define the size of
> a box? If the content in the box exceeds the box size, do we truncate or
> overlap? What does column and row mean? Does it mean that the page is
> pre-divided into well-defined grids?
[Sven] Consider the whole page a grid of rows and columns of standard width
and height (e.g. 6 lines per inch and 10cpi eg.)
Row 2, column 3 means a field should start with the top left point at "row
2, column 3". The size and width are per character. E.g, a hardcoded text
"TEXT" in 2 wide, 2 high would occupy 2 standard rows and 8 standard
columns. The formatters makes sure they draw within their lines (making e.g.
a font a bit smaller if no pixel-precision is feasible).
>
> > - The application triggering the print-outs uses 2 ways of requesting
> > it.
> > - Single reports: a report definition together with a "primary"
key
> > is sent to the application meaning "print the report for this
key"
> > - List of reports: an ordered set of report definitions with their
> > corresponding primary keys are sent to the application.
> > The list were required to get "transactions" in reports (a list
succeeds
> > to be printed if all reports in the list are printed) and to be able
> > to print off more than 1 report on a single page (e.g. PCL printers
> > throw out the paper when you issue the "print" command). A list of
> > reports
> > can be used to make something as: "a header, followed by a number of
> > small detail reports, followed by a footer).
>
> [Stanley] I suspect your requirement could be fulfilled by report
> parameters. Depending on the parameters passed in, different portions of
> the report can be printed. I am not quite sure what
|
|
|
| Re: UNIX printing [message #5126 is a reply to message #1697] |
Sat, 22 January 2005 02:00 |
| Eclipse User |
|
|
|
Originally posted by: sswart.fugen.com
Just having finished a large project where integrated reporting was a
critical success factor. I believe only targeting postscript / PDF is a
mistake. The reality I have experienced is most large applications have an
implicit requirement to print to legacy printers. In our case, we had both
laser and line printers -- and it was taken for granted that the leading
reporting tools support both equally well, they don't even come close to
supporting line printers well. If the BIRT project can even minimally [i.e.
columns, centering and alignment] support for text printers it will be a
large step above the status quo.
I am enthusiastic to hear that the project is abstracting the output engine
to allow for alternatives. If I have read the responses correctly.
--Shawn Swart
Director of Product Development
Premier Data Services
"Sven Boden" <svenboden@hotmail.com> wrote in message
news:crovr1$7b9$1@www.eclipse.org...
> Would BIRT support printing on UNIX on non-postscript printers?
>
> For example when BIRT would be integrated with an assembly line
application
> deployed on UNIX (granted it's not really business intelligence, but it's
> also reporting). Most of the big manufacturing printers can be turned into
> network printers, but most of them do not support PDF: Printronix,
> Mannesmann, ...
>
> A few problems for this kind of situation:
> 1) The printer escapes will somehow have to be generated (no Windows
printer
> drivers on UNIX), so this would require some kind of own "printer-driver"
> framework where escapes can be added per printer type.
> 2) For most assembly lines guaranteed delivery of manifests is critical so
> this would need some kind of active protocol towards the printer: instead
of
> putting the report output in a queue somewhere it would require
> communicating with the printer until the manifest is successfully printed.
> 3) It's possible the printer does not support 'free-form' on pixel level
but
> e.g. only on 'line level', e.g. text may only begin at certain vertical
> offsets. Which may have a manifest look a little bit diferent than in the
> designer.
>
> Regards,
> Sven Boden
>
>
|
|
|
| Re: UNIX printing [message #9025 is a reply to message #1697] |
Sun, 20 February 2005 12:18 |
| Eclipse User |
|
|
|
Originally posted by: ruurd.tiscali.nl
Sven Boden wrote:
> 1) The printer escapes will somehow have to be generated (no Windows
> printer drivers on UNIX), so this would require some kind of own
> "printer-driver" framework where escapes can be added per printer type.
Actually, more up-to-date printer demons like CUPS actually handle a lot of
mime-types and a lot of non-Postscript printers quite well, meaning that it
is possible to feed the demon PDF or PS or text/plain and the printing
problem can be given to the printer demon to handle.
> 2) For most assembly lines guaranteed delivery of manifests is critical so
> this would need some kind of active protocol towards the printer: instead
> of putting the report output in a queue somewhere it would require
> communicating with the printer until the manifest is successfully printed.
The downside there is that you need to have plugins for almost any printer
to handle their specific way of telling you the status of the document. And
there are many many printers out there each doing this in a different
way :-(
> 3) It's possible the printer does not support 'free-form' on pixel level
> but e.g. only on 'line level', e.g. text may only begin at certain
> vertical offsets. Which may have a manifest look a little bit diferent
> than in the designer.
You mean 'old-fashioned' line printing?
--
Ruurd
|
|
|
| Re: UNIX printing [message #9046 is a reply to message #2858] |
Sun, 20 February 2005 12:25 |
| Eclipse User |
|
|
|
Originally posted by: ruurd.tiscali.nl
Sven Boden wrote:
> Most of these have printer drivers for windows which probably convert
> application printing transparantly to their own escapes, but on UNIX
> you're mostly on your own since UNIX has no real printer drivers.
Just have a look at cups.org, which provides a transparent way of handling
printers. And, FWIW, have a look at linuxprinting.org for a myriad of
printer drivers. In fact, CUPS can provide binaries for AIX, HP-UX, IRIX,
Linux, and Solaris for about $10.
--
Ruurd
|
|
|
Goto Forum:
Current Time: Fri Sep 27 01:14:48 GMT 2024
Powered by FUDForum. Page generated in 0.04730 seconds |
] 
Search
Help
Register
Login
Home
