Paris Version 3 Information Pack
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Paris Version 3 Information Pack
Contents 1. Management summary 2. New features since Version 2 3. New features in Version 3 4. Xerox LCDS applications 5. New documents 6. Paris and Barcodes 7. Define 8. Advanced use 9. XLPrint software support 10. Version 3 upgrade strategy 11. Pricing 12. Training
Management Summary Paris, The Document System is a suite of software products from XLPrint Software, an International software house. XLPrint has been developing software in support of the laser printing and digital printing industries for over fifteen years. The first document creation product in the series was Lapres, launched in 1990. The Lapres concept of combining the design of a Form and Data at the same time was revolutionary and is a method followed by many others today. The Lapres product is installed world-wide and is enabling users of XES, Metacode and PCL laser printers to design, create and manage their documents. All this is possible without any requirement to modify or change business application programs. This means that the functions of data processing and document formatting are separated which means that skills are aligned to tasks. The Lapres software was designed from the outset with the user in mind, so it is fully WYSIWYG, and its ease of use became a benchmark. Users of Xerox LCDS printers in particular discovered that they could design applications without having to resort to the Xerox FSL and JSL command line languages. In 1996, the successor product to Lapres was launched – Paris, The Document System. Paris took all the concepts that had been invented within Lapres, to a new dimension by adding a rich array of features to support the growth of networked laser printing. By introducing a new concept of managing the printing requirement from a single networked Spooler, Paris is able to support a complete Enterprise Printing Solution. Output can be sent to any networked device, whether that is a desktop laser, a production laser printer, a digital press, a full color printer, and the new breed of multi-function devices or digital documents in PDF format. Paris followed Lapres into the market and proved to be extremely valuable as a way of creating new business documents as well as enabling a migration from either Line Printers or older technology laser printers. Document independence, ease of use and device independence are key strengths of the solution. Paris32 - 1998 In 1998, XLPrint announced the release of Paris32, which was effectively Version 2 of the product. The naming used the “32” so that it was clear that Paris Version 2 was a full 32 bit Windows product. Paris32 built once more on the stable feature / function set available from both Lapres and the first release of Paris and delivered a set of software modules that took full advantage of the Microsoft 32 bit application development environment. In addition, XLPrint responded to the many requests from customers and distributors alike that had been requesting even more functionality from the software. So, from Lapres to Paris Version 1 to Paris32, the feature /
function set grew to the point where the software was probably the most
competitive in its class.
Some of the new functions included were:
• Full color graphics
• Complex data driven charts
• Pie Charts
• Greyscale
• Exact currency conversions
• Customised Plug-ins
• VIPP support for graphics
• Server licensing
The “32” was dropped from the naming of Paris once all the customers
had migrated from the original version.
Paris Version 3
XLPrint are now pleased to announce Paris V3. With over 3,000 users
worldwide, Paris has been adopted by companies across all business
sectors - Manufacturing, Public Sector, Finance and Graphic Arts.
Full details of Paris V3 are provided in this document, but some key
features are:
• Dockable Data View Window
• Windows style icons
• New color selector
• Accounting System in Spooler
• Environment Listings
• Index file creation for archive systems
• Graphics compression
• Autosave
• Hex data display
• Event naming
• Cut and paste text importing from other Windows applications
The launch of Paris V3 will be during the first quarter of 2001 and it will
be a no cost upgrade to existing license holders of Paris Software. The
exception to this will be the Index File creation, which will take the form
of an API and will be a chargeable option.
This document provides a complete guide to Paris, The Document
System. It will enable both technical and non-technical people to fully
appreciate what Paris V3 can do – and more importantly, what Paris can
do for a Business.
Since the launch of Version 2 in 1998, there have been a number of new
features added to Paris. These have been either features added to Paris
itself, or contained in optional modules such as Bar Code and Define.
Although details of features that have been added in the last two yearsare available in other documents, they are summarized in this information pack. XLPrint Software February 2001 XLPrint USA Corporate Office 6320 Canoga Avenue, Suite 1500 Woodland Hills, CA 91367 Tel: (818) 598-1141 Fax (818) 598-1143 E-mail sales.usa@xlprint.com Website www.xlprint.com
New features since Version 2 Although there are major releases of Paris, such as Version 2 and Version 3, many new features are added in the period between these releases. The features are always published in the README file that is issued with each Build of Paris. There have been a number of Version 2 builds since its launch in 1998. The following is a list of new features that have been added to Paris. The current launch release (build) is available on the XLPrint FTP site http://ftp.XLPrintau.dynip.com New Features prior to Build 180 Page Shift: In the Environment/Output Settings dialog there is an option to shift the front and back pages to allow for hole-punched stock. This feature is now fully functional in PCL and Postscript. The shift applies to form and variable data and is specified in dots (300 per inch). Specify a positive value to move down the page and a negative value to move up the page. NEXTFILE: The NEXTFILE function has been improved and changed. NEXTFILE is the function where Paris can be instructed to output to a file while incrementing the file name to avoid overwriting the previous output file. The ability to split output files by a page-count has been removed from the NEXTFILE function and now applies to all output options (see next point). Output file name information (including directory names) can now be set per-destination (previously the NEXTFILE settings applied to all destinations). File Splitting: This function was previously available within the NEXTFILE output option but has now moved to the Job Definition dialog. In this way the ability to split an output file into many smaller ones (based on a page count) can be applied to all output methods. Resources will be reset (included) at the start of each file segment. Media Mapping: The Media Mapping function now includes the page-size parameter. This is only required if the application uses more than one paper size. If left blank Paris will specify the default size as that of the first page. The page size should be entered in points (rather than dots) which can be found in the PPD for the specific printer.
Media Mapping only applies to certain printers. For example any Xerox printer that uses the DocuSP controller. Multiple Engines: Paris Spooler now allows multiple Paris Engines to be running at the same time (Multi Tasking). This allows Paris to drive more than one printer at the same time and drastically improves system throughput speed. The Spooler now includes an additional menu item called Engines. For details on this function, see the online Help or the Paris Spooler Manual. TCP-IP LPD input option: The new 32-bit Paris Spooler has a new input option. The Spooler now includes an inbuilt LPD function allowing direct input from TCP-IP (LPR). See the online Help file or the Paris Spooler manual for more details. Port Monitor: Paris Spooler now also supports the ability to input directly from any Windows95/98 or NT printer queue. See the online Help file or the Paris Spooler manual for more details. Postscript Form and Image cache: Paris Spooler now takes advantage of the Postscript cache function to avoid downloading form and images for each page. The result is an extremely significant reduction in the size of output files. This enhancement is automatic. A similar feature already existed in PCL. GreyScale Palette: A new palette has been added. The palette contains the usual black in the first tablet and white in the second, with incrementally darker grey tones in the following fourteen tablets. These grey tones can be used as shade patterns on Postscript printers as an alternative to the current four density system (light, medium, heavy and solid) in Paris. The palette file is called GREYSCAL.PAL. A Paris form called GREYSCAL.FRM can be found in the Paris form directory which can be loaded into your Paris Form Editor and printed on a Postscript printer so you can compare the relative densities of the Grey tones/Shade patterns. NOTE: This palette will not work on NON-POSTSCRIPT printers. The shade patterns will print as solid black. Log File functionality: A LOG FILE option has been added to SETTINGS on the SYSTEM menu. This option lets completed job information to be saved to a file and a file name to write the log file to. There are log file clearing options:
1. Clear each time Spooler is started
2. Clear now
NOTE: The log file does NOT clear itself. If left uncleared the file
could quickly grow in size. The file is saved to the \PARIS\SPL\0
directory and the fields in each job entry are delimited with a caret "^".
Graphics enhancements:
Four graphic rotations supported, 0, 90, 180 and 270 degrees. Also,
color graphics will now print on non-color printers, (in black and white of
course).
New F6 dialog options:
1. CEP Spacing: This option has been renamed from 9700 Spacing.
2. New sheet on Input tray change: with this option checked,
coding a FEED= DJDE causes a NUFRONT to be applied
immediately.
3. DJDE channel skips generate blank lines: with this option
checked, a channel skip PCC on a DJDE record causes Paris to
output a blank line immediately following the record. This means
that the PCC is actioned at the new blank line, rather than being
buffered until a normal, non-DJDE record is encountered.
Stockset support:
For jobs that use FEED=stocksetname DJDEs we now offer support using
the Paris Media Mapping functionality. Enter the "stocksetname" into the
TYPE field of the View/Change Media Mapping Dialog and set the other
Media Mapping attributes as required. Paris then outputs the Media
requirements in the normal way to the printer.
NOTE: This functionality can only be used on Media Mapping capable
Postscript printers.
Resource Manager:
The packer/unpacker has been replaced by a resource manager. This
corrects numerous interface problems with the old packer/unpacker.
Paris Files that can be packed in the new packer:
Environments *.ENV
Forms *.FRM
Pagedefs *.PDF
Fonts *.LPF, *.TTF (new)
Graphics *.LPG, *.TIF, *.PCX, *.BMP
Translation Tables *.TLT
Input Filters *.FIL
Event Lists *.ELT
PCC Tables *.PCC
Environment Tests ENVCHG.SYSNew Keyboard shortcuts: - Opens Help file - Opens Resource Manager - Opens Font Reference Utility - Opens the Euro Rates Dialog New XPD command: Added to enable switching of Font encodings to more accurately map to the Windows display character set (Windows ANSI) when printing to Postscript printers. Add either of the following to an XPD file (found in the \paris\prt directory) as necessary: *XPDFontEncoding: Standard This tells the printer to use the printer's default encoding. This is the Paris default. *XPDFontEncoding: ISOLatin1 This tells the printer to use ISOLatin1 encoding which maps more closely to Windows ANSI encoding. New Graphics format: Paris now uses PCX as its internal graphics format. Backward compatibility with the previous Paris LPG format is maintained. New features in Build 180 New Field Operators: 1. Text rotate operators, (Rotate, RotateClrUnder, RotateClrOver) allow rotated text to be added at any angle to a page. The added text is not visible in the Designer. 2. System Variables, Date/Time/Page/Report, can now be added to a page. The values for Report and Page are the report and page counts extracted from the Paris formatting engine. Date and Time are the system date/time when the job was started. See the online help for details of usage. Barcode add-on: A new installable option that adds a set of TrueType Barcode fonts and supporting Paris code. This option must be purchased separately. The Bar Code option is described more fully elsewhere in the V3 launch document.
Resident Postscript Font support:
Full support for Printer resident fonts, with and without ATM installed.
The ability to change font encodings for resident fonts has also been
added (see previous XPD commands).
Enhanced Stockset support:
Added via the introduction of a mapping file "STOCKSET.XPI" which
allows users to map from "FEED=" DJDE commands to Paris tray names.
Enhanced DJDE Support:
1. MARGIN= Full support
2. FONTINDEX= Full support
3. XDOTS= Full support
New Spooler GUI :
1. Use of "splitter" windows in Paris Spooler to allow resizing of
Printer/Job display to suit user needs.
2. Ability to select multiple Jobs to perform group actions hold /
release / delete etc.
3. Introduction of tabbed dialogs
Preprocessor support:
A new feature set has been added to support the pre-processing of data
files by standalone programs, prior to the Paris formatting engine.
Examples of this would be the Xerox XES2PS package, output from
XLPrint’s Define package or user written code.
LPR control file support:
The contents of the control file from an LPR/LPD file transfer can now be
used in the both the Spooler and the Engine. See online help for details
of usage.
Enhanced Job reprint functionality:
New options added to enable users to select a range of pages to be
reprinted, in the Spooler.
Features added in Build 183
Copy Sensitive Processing implemented:
Copy sensitive/collated copies support added to Output Settings dialog.
(Details available in on-line help).Type 42 font handling: Support added for TrueType Type42 fonts on Postscript printers. Default is that the Type42 is turned off. It can be turned on via an XPD entry. For example: *XPDType42: True Type42 fonts offer the advantages of smaller print file sizes and better print quality. LPR Defaults Added LPR defaults dialog in Designer (details in on-line help) RTEXT via DJDE Added DJDE/RTEXT support (details in on-line help). RTEXT and RFORM that are in a compiled JDL are not supported. Features added in Build 185 OTEXT Enhanced OTEXT/User message options at run time (details in on-line help). This feature has been enhanced to allow a user to enter a Paris Field value at runtime. This is particularly useful when using Fields to number pages where the first page number is variable. New F6 dialog options: 1. Align overprint line baselines (details in on-line help). 2. Preserve CME events for begin (details in on-line help) LPR/LPD support enhanced: A new parameter to allow Users to set the maximum number of simultaneous LPD jobs received. This is to avoid a situation where print jobs are printed "out of sequence", in a first in first out basis, rather than the order in which they were sent. For example, a smaller job sent after a larger job, would finish downloading first and so, would be printed first. To implement this feature, add the following to the SPOOLER.INI file: LPDConnections=n
Where "n" is a numeric value between 1 and 5 and indicates the
maximum number of simultaneous jobs that can be received. The default
value is 5, if this line is not present in the Spooler.ini.
If there are problems with jobs printing out of sequence, set the
parameter value to "1", without the quotes.
Features added in Build 187
Page-oriented DJDE parsing:
A new INI file option has been added. It turns off support for line-
oriented DJDEs. These DJDEs become standard page oriented DJDEs,
which avoids a number of issues relating to copies and line/page
boundaries.
To activate this, add the following to the 'Paris.ini' file:
[Runtime Events]
LineRTCopies=False
DJDE "deactivation":
A new XPD entry to 'deactivate' DJDE commands has been added. Any
DJDE that Paris recognises can now be set to 'ignore', which means that
Paris will read and parse the DJDE, but then not act upon it. The syntax
is:
*XPDApplyDJDE djdestring: true/false
Where 'djdestring' is the ID string exactly as it appears in the data file.
Field Currency Change:
A new field function has been created that, when used in conjunction
with the currency to string (CUR2STR) function, will allow the user to
format a currency amount without the decimal places e.g. $23,000.00
can be shown as $23,000. The syntax is:
STRIPCHAR ( STRIPCHAR ( CUR2STR ( fieldname,".",",",3,FRONT )
,STRIP_END,"0" ) ,STRIP_END,"." )
PPD Keyword substitution:
A new feature has been added to enable non-standard keywords in
manufacturer supplied to be substituted with Adobe standard keywords.
The syntax is as follows:
*XPDKeyWordSub *original Adobe entry: *custom entry
e.g. *XPDKeywordSub *Duplex: *TR-DuplexSpooler Delay Function:
A new XPD function has been added that causes the Spooler to delay for
"nn" seconds at the end of each job. This feature is to make sure a
printer can keep up with the Spooler. The syntax is as follows:
*XPDPrintDelay: nn
DLF synchronize:
Changes have been made to the to better synchronize the updating of
DLF's when multiple engines are running. DLF’s are the download flags
that Paris maintains so that it knows which resources have been
downloaded to each attached printer.
Change to GDI output:
A change has been made that causes the name of the job submitted to
the GDI Spooler system will include the original file name plus the job
name.
Empty Activation Strings:
A change has been made to the PPD parser to avoid problems if it
encounters an empty activation string in a manufacturer supplied PPD
file
Increase in Internal Line Size:
In rare cases when multiple data change events were applied to a line
the maximum number of characters allowed in the internal line buffer
was exceeded. As each event adds a significant number of characters to
the internal buffer in some cases the internal limit of 1000 characters
could be exceeded. The syntax is as follows:
[Printing]
Maxinternallinesize=nnnn
These line should only be added if required.
Change to Job Ticket Activation:
The Job Ticket Activation has been changed to by-pass the Xerox specific
requirements.
Long Graphic Filenames:
The length allowable for a graphic filename has been increased from the
current limit of 8 characters to 27 characters.Change to Passthrough Code:
A new passthrough option has been added. The existing option,
'' means the engine will check the last byte of a passthrough job
to see if it is a Form Feed, and if not it adds a Form feed (to make sure
that pass through jobs are separated). The new '' option
suppresses this check - it is a 'true' passthrough, in that the file is not
checked in any way, and no extra chars will be generated.
- existing passthrough processing
- new optionNew in Version 3
Designer GUI Changes
Naturally the GUI is the most visible part of the system and there have
been a number of significant enhancements that do change the look
substantially. The changes are as follows:
Dockable Data View Window
The most obvious change to the GUI is the new data view window,
which provides the user with a significant amount of information about
the currently open environment. Much of this now readily available
information was previously only available via menu. The window is fully
resizable, movable and able to be closed. It is broken into three sections
by tabs. The first tab, information, contains general information about
the environment and the current page such as form name, current tray
etc. The second tab, current page def. contains all the relevant
information about the current page definition. Double clicking on an
entry will open the relevant dialog for editing/viewing. The final tab,
fields, contains the list of current fields. Double clicking on an entry will
open the field dialog.
Dialogs re-done
Many of the existing dialogs within the design system have been re-
worked to make them more “user friendly”. Cramped dialogs have been
expanded and the options laid out so as to be more easily selected.
Inconsistencies in some of the drop-downs have also been removed.
CEP options
A new CEP Options menu option has been created. This “makes visible”
the Xerox CEP options that were previous only available via the F6
function key.
New/revised icons
The designer contains some new icons plus some of the existing icons
have been modified. They include:
• Two new movement icons. These allow the user to lock/unlock
horizontal and vertical movement control.
• Two new grid icons. These allow the user to show and/or lock
the underlying grid.
• New settings icon. Allows the user to go directly to the settings
dialog.
• 3 new Zoom Icons. Allows user to zoom in/zoom out and zoom
to full-page view.
• New preview icon to switch to full color view.
• A new text alignment button with an associated popup menu
displaying the 3 alignment options.• A new text wrap icon to activate wrapping.
• New line weight, line style and fill style icons with popup menus.
• New draw and fill color icons with new industry standard popup
color selectors.
Data Edit – Hex
A hex display has been added to the edit data option in the file menu.
This allows the user to view the incoming data in either ASCII or hex
from within Paris.
New color selectors
Wherever color is available in the designer i.e. for fonts, lines, boxes,
etc. the existing 16 color selector has been replaced by a new industry
standard color selector. This new selector gives access to the full range
of Windows RGB colors. Color palettes can be created/loaded/saved and
modified.
Text editing menu item
A new menu item has been created to display the various keyboard
shortcuts available within the designer. The menu is context sensitive so,
depending on what action is being performed in the designer, the
appropriate entries will be available or ghosted.
If the Designer is in Text Mark mode, this is indicated on the status bar.
Named events
All events within the system can now be named. This provided a new
level of usability throughout the Paris event sub-system making events
easier to identify.
Input filter changes
The input filter dialog has been changed to better display the
information. This includes the addition of both a hex and literal display in
addition to the original decimal display.
Nudge feature
A nudge feature has been added. This enables Text Blocks to be
positioned accurately by moving in small increments, both horizontally
and vertically.
Accounting System for Spooler
This is a totally new system. The main intention of is to allow users
access to the following information:• The total number of jobs printed since a given date;
• The completion status of any given job;
• The number of pages printed for a given job;
• The total number of pages printed since a given date.
The accounting system keeps track of the flow of jobs through the
spooler. The normal flow is for a job to ‘arrive’ at one of the spooler’s
input sources, be queued for printing, be printed by the Engine, and
then deleted. There are a few variations on this basic situation. First, a
queued job can be deleted before it is printed. Second, a job that starts
printing can be aborted (either by the user or the Engine). An aborted
job is requeued immediately, and will either be ‘released’ for printing or
deleted.
All of this combined means that there are 2 ways for a job to ‘enter’ the
system - queued, and re-queued (after an abort); and there are 3 ways
for a job to ‘leave’ - ‘printed’, ‘aborted’ and ‘deleted’. In the case
‘aborted’, the job does not really ‘leave’ - it simply re-enters the system
as ‘re-queued’.
Each entry in the accounting info represents a job that has reached one
of the 3 possible completion states. Each entry contains the following
information:
1. Input file name
2. Input source (LPD/Disk.etc)
3. Initial ENV (we don't track DJDE changes!)
4. Initial Printer (we don't track DJDE changes!)
5. Initial Copies (we don’t track DJDE changes!)
6. Date/time queued
7. Completion Status (Printed/Aborted/Deleted)
8. Date/time Completed
9. Pages printed
User’s Perspective
The user will be able to do the following with the Paris account system:
• View on screen a list of the all the current accounting
information.
• Show the entire list of completed jobs, sorted by the following
attributes - date/time, ENV, output printer, completion status.
• Filter the list of jobs via the same attributes - show jobs in a
given date/time range (i.e., ‘last 3 days’, ‘last week’, etc), with
selected attributes (ENV, output printer, completion status)
• Show a page total for the currently displayed list of jobs.
• Manage the accumulated accounting info.
• Completely clear the accounting info;
• Export the current accounting info to an external file (in XML
format)
• Output all Details for entries in the current ‘view’
• Output all details for all entries.
• View and change the settings for accumulating accounting info.• Decide what to store
• Decide How much to store (and when to clear automatically).
Environment Listings
This new system fulfils requirement for a utility option in the Paris
designer to allow the contents of an ENV to be written to disk in a
human readable form – probably for printing. There are three main
reasons for this:
1. As a documentation aid – a hardcopy, human readable print out
of an ENV can be used as part of the documentation for a Paris
installation.
2. To ease the recreation of ENVs if they are lost or corrupted, or
need to be recreated in a situation where the original ENV is not
readily available. The listing can be used to gather the
necessary information to be entered into the designer when
creating an ENV.
3. As a ‘quick reference’. Being able to access or print ENV
contents without opening the designer.
The ENV file is currently a binary file format that can be viewed and
edited only through the designer. The ‘ENV listing’ utility will convert
binary ENV files into a human readable (and printable) equivalent.
Editing an ENV must still be done via the designer – the human readable
version is for viewing only.
User’s Perspective
The user will be able to do the following with the ENV Listing function:
• Display a dialog that shows a list box containing the current files
to be ‘translated’. This list would be initially empty.
• Add and remove ENVs to the ‘translation list’.
• Set options and output for the translation, including selecting the
‘style’ of output.
• Start the translation.
Paris Archiving Support
Paris now has the ability to prepare files for third party back end
archiving systems. This is achieved through a combination of existing
Paris functions plus newly developed features.
The job separation feature in Paris is utilized to break a large input file
into individual pages/reports. The existing Paris field system has been
enhanced to allow fields to be flagged as index type entries. A totally
new indexing menu option has been added to allow the user to configure
how the index entries are to be written out. Finally the existing
NEXTFILE feature has been expanded to allow the user to have morecontrol over the file naming of files produced by Paris, including the
addition of batch numbers.
A combination of all these features allows Paris to take in a datafile,
extract indexing information, produce individual output files (which are
normally distilled to PDF) and a corresponding index file. These files can
then be swept into any standard archiving system.
Designer Indexing Options
The Paris field function has been enhanced to provide the user the ability
to save any fields selected from the page into a file. This file becomes
the perfect mechanism by which Paris can describe the detail on the
page to any third party archiving system
Rather than be limited to just one archiving system the user is able to
customize how the indexing information is to be output. This should
provide the required flexibility to work with any third party system. This
is achieved via the new Indexing options dialog. A new menu item has
been added to the Designer. This new option Indexing is found under
the environment menu. This option provides the user with the ability to
format the way the index file is to be created.
Enhanced NEXTFILE options
The existing NEXTFILE function within Paris has been expanded to
provide the user with a far greater degree of control over file naming of
the output files. The file naming can now include a batch number and
date plus sequential numbering. In combination this provides all the
flexibility necessary to uniquely identify the output files in preparation for
archiving.
Spooler Changes
GUI changes
The following changes have been made to the GUI of the spooler
A row of icons has been added to access common tasks. The icons
perform the following functions:
• View/edit spooler settings
• Make printer online/offline
• View/change printer settings
• Delete current printer
• Change status of current job
• View/change job settings
• Add job
• Delete job
The main display lines in the spooler now change color (grey/black) to
indicate status. (e.g. an offline printer is shown gray; online printers are
shown black). The same applies to the job entries.Printer Pooling It is now possible to define and group together individual printers into a “pool”. This is a useful way to add some further control of the printing function to the Paris spooler. For example if the user has some high-speed production printers and some desktop printers, 2 “pools” could be set up. The first “pool” might be named production and would contain the high-speed devices. The second pool, desktop would contain the low speed devices. This makes it simpler to direct jobs i.e. all big jobs are sent to the production pool, all small jobs to the desktop pool. Updating Environment files in Spooler New code has been developed that now allows changed environment files to be loaded in the Spooler while the Spooler is running. Previously files were cached which caused a potential situation where a modified environment unpacked while the printer. Spooler display The Spooler displays can now be re-ordered by clicking on the column heading. Graphics compression Graphics compression has now been added into Paris. This will make the output files created by Paris considerably smaller. This is especially important for color applications. There are now 3 options for graphics compression that are activated via a new XPD entry. Graphics compression is activated by adding the following new line to XPD file. *XPDGrafCompression type Where type can be one of the following: 1. None 2. RLE 3. Flate For example to enables zlib deflate/flate compression the following line would be added to the XPD. *XPDGrafCompression: Flate If the XPDGrafCompression keyword is not present within the file, then the default is None.
Using ether RLE or flate invokes the new graphics handling system. The
new system achieves a 30% reduction on output size compared to the
new system even when no additional compression is achieved. This
benefit is the result of using a more efficient encoding available on level
2 PS printers.
The differences in the 3 compression options are as follows:
None
This is a special type that restores the old graphics handling. Output
from this method is identical to the previous version of Paris. This does
not have the benefit of the new encoding system.
RLE
• Works with postscript level 2 and up printers
• Not very good on color images (only 1% - 2% reduction in some
cases).
• Only has a very small impact on Paris engine throughput.
• On simple images (like black and white) it typically achieves a
20% reduction.
Flate
• ZLib flate./deflate compression (used in zip files and some kinds
of graphics files (png) )
• Level 3 postscript only
• Good with all types of images
• Has some (in some cases large) impact on Paris engine through
put; recommend downloading graphics to printer so that the
compression cost is one time only.
• Compression can be typically around 65% on most color images
and 85% on simpler images like most back and white.
Other Notes
• Flate only works on level 3 postscript printers.
• Using flate on smaller printer can slow them down significantly
• Recommend use of *XPDManageGrafs: Download with flate
so that graphs are only compressed at the beginning of a job
instead of every time they are used.
Cut and Paste
-
A new cut and paste facility has been added for text. This now makes it
possible to do a standard Windows copy or cut of text from another
Windows application, such as Word, and paste this text into the Paris
designer while in text add mode. This provides a ‘clean’ way to get spell
checked text from another Windows application into Paris. The text is
first copied or cut from the Windows application via a standard “ctrl X”,
“ctrl C” or menu. This text is then pasted from the Windows clipboard
into the Paris designer by doing a “ctrl P”.Notes:
• Text can only be pasted when in text add mode in Paris.
• Lines ends will be lost
• The font used will be the active font at the time
Autosave
Files open in the designer are now saved automatically after a definable
number of minutes. This minimizes the risk of changes being lost
through a non-recoverable problem. A new option appears on the
file/settings menu. This dialog allows the user to configure the time
interval (in minutes) between autosaves. This feature can be turned off
within the same dialog if required.
Page Suppression
A new Page / Para event has been added. This allows users to optionally
suppress a page from being printed through the Spooler if the event
tests are satisfied.
In the new Designer View window, a new entry shows whether a page is
to be printed or suppressed. In this way, the application designer is able
to see the page that would not be printed, allowing the correct logic to
be developed.
Blank line handling
Text block options have been expanded to allow blank lines (i.e.: no
printable characters in printable range) to be handled differently to non-
blank lines. A new check box and drop down menu have been added to
the view/change text block menu. The options for handling blank lines
are as follows:
• Printed – the line is treated normally
• Removed – the line is simply removed both in the editor and at
print time, but any special conditions such as font changes,
spacing characters are still honored.
• Moved to the top – the blank line/s are moved from their current
position in the text block to the top.
• Moved to the bottom – exactly the opposite behavior to the
previous option in that the blank lines are moved from their
current position to the bottom of the text block.
Floating text blocks
This powerful new extension to text block handling allows the user to set
up a text block with a positioning on the page that is relative to the
length of the previous text block. A new check box “relative” has been
added to the text block dialog. When checked this will allow this text
block to float vertically relative to the last line of the previous text block.This new floating text block feature is particularly useful in combination
with the new blank line handling. For example name and address blocks
with blank lines can first be compressed using the blank line handling
and then by giving the following text block a characteristic of relative it
will float up and down relative to the last line of the previous text block.
Graphics Preview
The add graphics dialog now has a preview button. The preview button,
as the name implies, allows the user to “see” the graphic currently
selected before adding it to the page.
Time scheduling for Spooler jobs
This will allow jobs to be submitted to the Spooler and held until a pre-
determined time before being run. It can be used to allow large jobs to
be scheduled for formatting after hours. It is set in the view/change
printer settings dialog in the new scheduling section.
The options are:
• Always. Meaning the job with print as normal in the spooler
• Between. Which allows the user to enter the hours between
which the job/s is to be printed.
Engine to printer assignment in Spooler
This new feature allows the user to link a printer/s to a particular engine.
In some situations where many small jobs are being printed to disk at
the same time as normal print jobs to a printer this can be an
advantage. By linking the printer to a particular engine, the engine does
not need to keep changing its “personality” for the different printer
types. This option is found in the view/change print engines dialog.
Detail or list in File/open dialogs
The file open dialogs now contain icons to switch between detail and
simple list view of the files.
Runtime parameter editing
The Runtime Events feature has been extended. It is now possible to
edit one or more Runtime Events so that specified commands that may
be embedded in the data can be changed – or even removed. Runtime
Events include most Xerox DJDE commands.
Using this feature, files with unwanted or unnecessary DJDE commands
may be edited without the use of a Paris pre-processor.
Field Calculation OptionsWhen using the Calculation function in the Paris Fields system, the available options can now be displayed. This is done by simply clicking on the “ ? “ box. Basic syntax is also shown. Full details of the Calculation options are in the Documentation and Help files.
Xerox LCDS Applications
Background
The Xerox LCDS architecture was developed in the 1970’s. Its aim was to
provide users with the ability to take print files designed to print on an
impact printer and enhance those print files before printing on a
production class laser printer.
The philosophy of the architecture was to use an Electronic Sub System
(ESS) as the interface between the customer’s computing system and
the printing engine, referred to in Xerox terms as the Image Output
Terminal (IOT).
The ESS software has been steadily developed over the last twenty
years, but the overall architecture has been stable. This has meant that
users of the first generation systems (9700/8700) have been able to
upgrade their printers to second generation systems (4050/4090/4135)
and from there to the current range of printers
(4635/4890/4850/DP180/DP96). While the hardware changes were
made, little or no changes were required to the applications that had
been developed, except to take advantage of new hardware capability
such as highlight color, connectivity or flexible stock sizes.
One of the most powerful features and a significant that have been part
of the architecture from the outset is the Dynamic Job Descriptor Entry
(DJDE). DJDE’s offer a way of setting up a production printing operation
in which the hardware printer operators were not involved in the
selection of the printer features for any particular job. This meant that in
a well set up operation, the commands, such as tray selection, font
changes, duplex, etc. that instructed the printer were part of the print
file and were interpreted as commands, not print data.
So, the DJDE performs two distinct functions: the ability to create
advanced applications by means of commands that could change a
document appearance on a page-to-page basis, and the ability to
automate operations.
In principle, the DJDE feature is simple to understand. In practice
however, the implementations vary widely. DJDE printer commands may
appear in a number of ways to achieve different results. For example:
• As a single record at the start of a print file, so that the printer
features selected are constant for the whole job. This single record
would be a simple link to a full description of the formatting rules
stored on the ESS.
• As a batch of records at the start of a print file. This is the same
concept as above, but gives more flexibility to change the whole job
without having to modify any files on the ESS in order to change the
appearance of the document.
• Single or batches of records at the start of each page of a print file.
This gives the added opportunity to change the appearance of aprint file every page. In many cases, user application programs have
been amended so that these DJDE records are created alongside the
application data.
Within this overall framework there are a large number of actual printer
commands, and each one of these has its own syntax which may or may
not allow different interpretations on its format, such as abbreviations.
The consequence of all the above is that there are a large number of
customers who have invested heavily in the Xerox printing architecture.
It has been a good investment for many years.
Why Change
The reasons that some users of the Xerox printing architecture may be
thinking of change are many. For example
• The ESS, which is the original concept, is very competent and
efficient, but it does not allow the customer to take full
advantage of what is available from the printing engines (IOT’s)
that are available today.
• The growth of laser printing in the office has meant that user
expectations of document content and design have moved on.
• Applications that may once have been developed on a host
system may now be developed on a network platform. The
Xerox ESS / IOT architecture does not lend itself to being a
network device without some form of interface.
• Applications developed on a network may well already be
formatted using PCL or Postscript. Neither language is native to
the Xerox ESS / IOT and requires a transformation prior to
sending to the ESS.
• IT printing may well be merging with digital reprographics.
The Challenge
The challenges for customers as they consider their next step are:
• Take full advantage of what printing technology offers.
• Make sure past investments are maximized.
Migrations using Paris
One of the features of the Paris software is its ability to process and print
applications that have been designed to print on the LCDS printers,
which are:
• 9700
• 8700
• 9790
• 8790
• 4050
• 4090• 4650
• 4135
• 4850
• 4890
• 4635
• DP180
• DP96
• DP92C
• 4235 (XPPM Mode)
There are two stages to the process.
1. Conversion of printing resources. These are the user files that are
stored on the Xerox ESS. Paris is able to read these resources and
convert them for use with the Paris system. The conversion is
once only for each resource. The file types are JDL, CME, PDE,
FRM, FNT, IMG, and LGO
2. Processing the print jobs. This is the production side of Paris and
requires Paris to scan the print file for Xerox printer commands
(DJDE’s) and emulate the processes of the Xerox ESS. The
difference is that Paris will produce a Postscript or PCL file that can
be subsequently printed on any Postscript or PCL capable printer
attached to the network.
However, conversion of print applications is really only the first stage.
Once an application is converted into Paris, and the DJDE printer
commands are being correctly actioned, the user has the opportunity to
use all the features of the Paris system to improve and enhance the
document, so taking full advantage of the printing power on the
network. A full list of supported Xerox network printing devices is
published elsewhere, but the categories of product are:
• Docuprint (NPS) Printers
• DocuTech Production Publishers
• Network Printers
• Desktop and Personal Printers
• Document Centres
• Docucolor
The Xerox DJDE commands that are supported by Paris are listed in the
Documentation. Where there is a DJDE, or Xerox JSL feature, that is not
directly supported by Paris, it is very likely that a similar feature with
more power and flexibility will be available.
As an example, Paris does not directly support the Xerox NUMBER
feature, which gives page numbering. But, using the Paris Fields
functions, the Report Number, Page Number, Date and Time may be
added to a document. Over and above this, the Field feature may be
used to number sides OR logical pages – something the Xerox NUMBER
feature does not do.Positioning When a customer is considering moving away from the Xerox LCDS architecture to a Network oriented system there are key differences in the methods available that need to be understood. The simplest method is a data stream transform. In general, the products that use this technique will provide a one to one conversion of the LCDS data stream to another data stream such as IPDS, Postscript or PCL. While this may overcome an initial problem of moving jobs from one printer type to another, it does not address the more important issue of how to make changes. In most cases, the changes will need to be made to the Xerox LCDS resources, so that the conversion can work. So that this requirement can be serviced, the customer will need to maintain LCDS knowledge and skills in order to be able to make application changes. Uniquely, Paris does not work like this. The Paris is a one off conversion of Xerox resources so that these resources are available to the normal Paris Design system. Once they are in Paris, they can be edited and enhanced in the same way as if they were created as new resources. So, there in no requirement to keep the original Xerox resources except for security and archive purposes. So, the key positioning statement is that Paris is an application migration solution NOT a data stream transform product. 100% of Paris customers use the Designer to create their documents. 40% of those started out as users of Xerox LCDS printers and migrated their applications into Paris. This information pack contains a presentation that fully explains the philosophy behind the Paris method of migrating LCDS applications so that they can be printed or archived.
New Documents
Background
60% of new Paris customers are purchasing the product to develop new
applications as opposed to migrating LCDS applications. Of the 40%
whose initial use of Paris is to migrate their LCDS applications, the
majority of these customers will use Paris to either develop new
applications or modify existing applications within the first six months or
purchasing Paris.
Paris has been developed as an application design tool for Postscript and
PCL printers. It is a follow on product to the successful Lapres software,
which has been installed in large numbers worldwide in support of Xerox
LCDS and XES laser printers.
As the 1990’s progressed, XES was discontinued and development of the
LCDS architecture slowed. With Postscript and PCL becoming the de-
facto standards for the growing office network printing market, Paris was
developed as a “printer-centric” solution.
With the development of Postscript and PCL came more document
related features, better quality printing with outline fonts, the ability to
image more complex pages, color and multi-functionality. Paris enables
customers to take full advantage of their hardware investments.
Accessing and using advanced document design is not so easy for
business applications since these applications create their output as data
that is best described as un-formatted, or data that is being sent to a
printer with less capability than a laser printer, such a line-printer or dot-
matrix printer.
This is a key reason why Paris has been developed. Paris enables a user
to create Postscript and PCL documents from unformatted data. This
data may be ASCII, EBCDIC or exported from a database as a record
delimited file. It does it in such as way that the user can have access to
all the features of the laser printer, without changing the business
application.
Paris
Paris is a Windows application. Users will soon become familiar with its
features and functions. The big advantage is that Paris operates within
the environment in which users are already knowledgeable. Desktop,
mouse and keyboard knowledge are the starting point.
When a new document is being planned, there are three types of
information that may form part of the final design.
• Fixed Form information
• Variable Form information• Variable Data
All three types of information are viewed on the screen at the same
time, and each may be edited so that the user can see the effect of any
change on the document as a whole. The document designer is always
designing the whole document, not a part of it.
Fixed Form Information
This is information on a document that is going to be the same on every
page. The incoming variable data can be used to change the fixed form
information on a page-to-page basis. Examples of fixed-form information
would be Company Logo, Company name / address, lines and boxes that
are designed to contain incoming data.
Variable Form Information
This is similar to fixed form information, but differs in that information
within the elements can change depending on the incoming data. For
example, an electronic signature may move up or down the page
depending on the length of a letter. Or, a box designed to contain lines
of specific information may lengthen or shorten depending on how many
lines are received. Or, a person’s name may be extracted from the
incoming data and used in the body of a letter.
Variable Information
Paris can manipulate the incoming data in a variety of ways. This to
some extent depends on the format of the data, but there are many
features within Paris that allow greater freedom of design when used in
conjunction with the Form Information. These include:
• Access to the TrueType and Adobe Font Libraries
• Ability to call in over 30 different types of graphic format
• Creation of Bar Charts, Histograms or Pie Charts from incoming
data
• Mathematical capability used to calculate new values from
incoming data (GBP to Euro for example)
• Columns, tabs and justification
• Text rotation
• Duplication of data
• Suppression of data
• Selection of data
• Full use of color
All of the above is managed in the Paris Designer software. Test data is
normally used to design the document and proofs can be taken at any
time by printing to any Windows attached printer. When the design is
complete, it is stored within the Paris system and can be used in
production.Business Sectors
Paris is used across all business sectors; it is not limited to a single
business type. The factors that influence a Paris installation are:
• Document content
• Print volume
• Data source
• Printer location
• Ease of use
• Change of business requirements
• Features / functions
• Value for money
• Support
• IntegrationParis and Barcodes An advanced system to support the creation of documents that require Barcodes was launched in 1999. This is a chargeable option and requires a license string. The option comprises the software tools that enable the correct character strings to be created for any of the supported Barcodes and the Barcode fonts. The Paris on-line help and PDF documentation explains how to use the barcode features. Listed below are the most common Bar Code Symbologies including a partial specification for each symbology. In general, Code 39 is the most popular of all the symbologies. The symbology used in an application will depend on the requirement of the system that is reading the barcode, which could be a mailing machine, a check-out till, a hand-held scanner or a warehouse distribution system. Code 3 of 9 Code 39 is variable length and is the most frequently used symbology in industrial bar code systems today. The principal feature is to encode messages using the full alphanumeric character set. Three of the nine elements (bars) are wide and six elements are narrow. The Code 3 of 9 bar code uses four special characters "$", "/", "+". "%", which can be paired with alphanumeric characters to extend to the full ASCII character set. Listed below are the options for the Code 39 symbology. Full ASCII Standard Code 39 contains only 43 characters (0-9, A-Z, $, /, %, +). Code 39 can be extended to an 128 character symbology (full ASCII) by combining one of the special characters ($, /, %, +) with a letter (A-Z) to form the characters that are not present in the standard Code 39 symbology. For example, in standard Code 39 a lowercase "a" cannot be represented. In Code 39 Full ASCII, however, "a" is represented as "+A". Check Digit A modulo 43 check character can be used to enhance data security for Code 39 symbols. The last digit of the symbol is assumed to be the check digit, and it is compared to a calculated check digit to verify the symbol. Append It is sometimes advantageous to break up long messages into multiple, shorter symbols. If the first character of a Code 39 symbol is a space (ASCII 32), then the scanned symbol is appended to a storage buffer. This operation continues for all successive Code 39 symbols with a leading space being added to previously stored ones. When a Code 39 symbol is scanned which does not include a leading space, it is
appended to the buffer, the entire buffer is transmitted, and the buffer is cleared. Universal Product Code (UPC) UPC-A UPC-A (Universal Product Code-A) is fixed length and is the most common UPC bar code for retail product labeling and is seen in most grocery stores across the United States. The symbology encodes a 12- digit numeric only number. The first six digits are assigned from the Uniform Code Council (UCC) in Dayton, Ohio, the next five digits are assigned by the manufacturer, and the final digit is a modulo 10 check digit. The nominal height for the UPC-A bar code is one inch. The reduced size is 80% of the nominal size. UPC-E UPC-E (Universal Product Code-E) is also fixed length and is a compressed six-digit code used for marking small packages including magazines and paperback books. UPC-E symbols are UPC-A symbols that have been zero suppressed (i.e. consecutive zeros are not included in the symbol). The printed value of the UPC-E code is a twelve-digit code. The nominal height for the UPC-E bar code is one inch. The reduced size is 80% of the nominal size. European Article Numbering/Japanese Article Numbering (EAN/JAN) EAN/JAN-13 The EAN/JAN-13 is fixed length and is similar to the UPC-A symbology, but encodes a 13th digit. The 12th and 13th digit define the country code. The code 00-04 and 06-09 are assigned to the United States. The nominal height for the EAN/JAN-13 bar code is one inch. The reduced size is 80% of the nominal size. EAN/JAN-8 The EAN/JAN-8 is fixed length and is similar to the UPC-E code, but includes two more digits for the country code. The nominal height for the EAN/JAN-8 bar code is one inch. The reduced size is 80% of the nominal size. Interleaved 2 of 5 Interleaved 2 of 5 is a variable length, even numbered, numeric bar code. It is typically used in industrial and master carton labeling. The symbology uses bars to represent the first character and the interleaved (white) spaces to represent the second character. Each character has
two wide elements and three narrow elements. Listed below are the options for the Interleaved 2 of 5 symbology. Check Digit A modulo 10 check character can be used to enhance data security for Interleaved 2 of 5 symbols. When this option is selected, the last digit of the symbol is assumed to be the check digit, and it is compared to a calculated check digit to verify the symbol. Code 128 Code 128 is variable length and encodes the full 128 ASCII character set. Each character is represented by 11 modules that can be one of four bar widths. Code 128 is the most easily read code with the highest message integrity due to several separate message check routines. Of all the common linear symbologies, Code 128 is the most flexible. It supports both alpha and numeric characters easily, has the highest number of characters per inch, and is variable length. Code 128 is usually one of the best choices when implementing a new symbology. UCC/EAN-128 Inserts a unique, reserved start code, Function Code 1 (FNC1) for application assignments by the UCC and EAN. The initial digits are interpreted as Application Identifiers (AIs). Append It is sometimes advantageous to break up long messages into multiple, shorter symbols. If the first character of a Code 128 symbol is a Function Code 2 (FNC2), then the scanned symbol is appended to a storage buffer. This operation continues for all successive Code 128 symbols with a FNC2 being added to previously stored ones. When a Code 128 symbol is scanned which does not include a FNC2, it is appended to the buffer, the entire buffer is transmitted, and the buffer is cleared. Special Characters When calling the DLLs, use the following keyboard characters in the input string to insert the Special Characters: FNC1 (Alt+185), FNC2 (Alt+178), FNC3 (Alt+179), and FNC4 (Alt+188). Codabar Codabar is a variable length symbology capable of encoding 16 characters within any length message. Codabar can encode six special alphanumeric characters, capital letters A through D, and all numeric digits. Codabar symbology for any new applications today should not be considered except under unusual circumstances. Listed below are the options for the Codabar symbology.
You can also read
