Difference between revisions of "Printing subsystem"

From Inkscape Wiki
Jump to navigation Jump to search
(Removed spam)
 
m (Frigory moved page PrintingSubsystem to Printing subsystem: Separated words)
 
(4 intermediate revisions by 2 users not shown)
Line 4: Line 4:


# Configuration -- destination, page size, orientation, etc is selected, the "Print" dialog
# Configuration -- destination, page size, orientation, etc is selected, the "Print" dialog
# Output -- DOM is coverted into a some kind of output, like PostScript
# Output -- DOM is coverted into a some kind of output, like [[PostScript]]
# Delivery -- "Output" is delivered to the selected destination
# Delivery -- "Output" is delivered to the selected destination


GnomePrint will let us do our own "Output" stage.  They also have their own.  Inkscape's native PS output, however, uses raw PS writing, rather than generic "moveto" kinds of actions, which is how GnomePrint is set up to be called.
[[GnomePrint]] will let us do our own "Output" stage.  They also have their own.  Inkscape's native PS output, however, uses raw PS writing, rather than generic "moveto" kinds of actions, which is how [[GnomePrint]] is set up to be called.


My remaining questions:
My remaining questions:
* Will GnomePrint apply "Configuration" selections (page size, orientation) to application-generated Output correctly?  It does not, however, these parameters are available during the "Output" stage, since they are collected during the "Configuration" stage.  See "example_11.c" that comes with libgnomeprintui2.2.
* Will [[GnomePrint]] apply "Configuration" selections (page size, orientation) to application-generated Output correctly?  It does not, however, these parameters are available during the "Output" stage, since they are collected during the "Configuration" stage.  See "example_11.c" that comes with libgnomeprintui2.2.
 
 
(question: some printer drivers uses to print, instead to hardware printers, to .pdf files - is there existing drivers to print to raster pictures like .bmp, .png, and so on?)
 
(suggestion: one of the most interesting feature of a vectorial editor, when focused to printing (postscript printing), is defining on each vectorial shape, halftone patterns oriented by an angle grid, like dots, squares, lines, etc. ) - with the inkjet printer popularization, this so amazing feature simply disappeared (aka being very limited to the driver printer halftone choices), which its simulation (at least) is very, very welcome!) (note: you could do nice halftone printing on Aldus(!) Freehand 3 with postscript printers  at late '80s or early 90's !!!!)
 
---
 
With printing in mind, distinguishing between "page" and "paper" is
indeed important. Take for example a real world task of creating
a portfolio with no margins (graphics reaching to the edge). Due
to imprecision in printing, you need bleed (at least 3 mm in each
direction for offset printing, rather more if it's a copy-shop job).
And cropping marks. If you also need a PDF for screen display, you
either need a tool that can crop on export, or you need to create
2 versions.
 
In the PDF and printing world, things are a bit more complicated than
just "page" / "paper", though:
http://www.tgreer.com/printforum/showthread.php?p=265
http://bugs.scribus.net/view.php?id=1041
 
---
 
It is logical that the paper size should be shown, because a user will
want to know, what the finished product will look like. There then
should be a printing margin, a layout margin (framing the main place for
putting element) as well as an adjustable bleed.
A view setting will allow the user to hide everything but the pages and
also blank the parts on the page, that are not printable.
A menu like the layer menu will allow easy navigation between pages.

Latest revision as of 05:52, 13 July 2016

These are the notes I've taken away from examining the printing subsystem. -Kees 2004-04-17

Printing in Inkscape depends on three components:

  1. Configuration -- destination, page size, orientation, etc is selected, the "Print" dialog
  2. Output -- DOM is coverted into a some kind of output, like PostScript
  3. Delivery -- "Output" is delivered to the selected destination

GnomePrint will let us do our own "Output" stage. They also have their own. Inkscape's native PS output, however, uses raw PS writing, rather than generic "moveto" kinds of actions, which is how GnomePrint is set up to be called.

My remaining questions:

  • Will GnomePrint apply "Configuration" selections (page size, orientation) to application-generated Output correctly? It does not, however, these parameters are available during the "Output" stage, since they are collected during the "Configuration" stage. See "example_11.c" that comes with libgnomeprintui2.2.


(question: some printer drivers uses to print, instead to hardware printers, to .pdf files - is there existing drivers to print to raster pictures like .bmp, .png, and so on?)

(suggestion: one of the most interesting feature of a vectorial editor, when focused to printing (postscript printing), is defining on each vectorial shape, halftone patterns oriented by an angle grid, like dots, squares, lines, etc. ) - with the inkjet printer popularization, this so amazing feature simply disappeared (aka being very limited to the driver printer halftone choices), which its simulation (at least) is very, very welcome!) (note: you could do nice halftone printing on Aldus(!) Freehand 3 with postscript printers at late '80s or early 90's !!!!)

---

With printing in mind, distinguishing between "page" and "paper" is indeed important. Take for example a real world task of creating a portfolio with no margins (graphics reaching to the edge). Due to imprecision in printing, you need bleed (at least 3 mm in each direction for offset printing, rather more if it's a copy-shop job). And cropping marks. If you also need a PDF for screen display, you either need a tool that can crop on export, or you need to create 2 versions.

In the PDF and printing world, things are a bit more complicated than just "page" / "paper", though: http://www.tgreer.com/printforum/showthread.php?p=265 http://bugs.scribus.net/view.php?id=1041

---

It is logical that the paper size should be shown, because a user will want to know, what the finished product will look like. There then should be a printing margin, a layout margin (framing the main place for putting element) as well as an adjustable bleed. A view setting will allow the user to hide everything but the pages and also blank the parts on the page, that are not printable. A menu like the layer menu will allow easy navigation between pages.