Q: What is AFP ?

A: AFP is the IBM Printing Architecture and provides final-format document datastreams, line-print compatibility and printer management functions using IPDS.

Q: What is MO:DCA ?

A: MO:DCA stands for MixedObject:DocumentContentsArchitecture and is the basis for AFP. All resources such as fonts, logos, forms and graphics are clearly defined and fully published in this architecture, which is used by a number of IBM products. MO:DCA is fully documented and therefore a truly open architecture.

Q: What is the ISIS relationship to IBM ?

A: ISIS Holding AG is a completely privately owned group of companies. There are Business Partner relationships to IBM in many countries where ISIS products are sold through IBM channels. ISIS does not sell any IBM products but provides skill and manpower to many IBM projects as a Project Associate.

Q: Can ISIS AFP products be used only with IBM printers ?

A: No. While the strategic ISIS architecture is AFP, which is IBM-defined, it supports printers from all major manufacturers. As the advantage of AFP is the standard interface between applications and the printer HW, there needs to be a 'Print Management Software' used at the time of print.

On the IBM platforms, this is IBM PSF for IPDS printers. Other manufacturers including ISIS, I-data, Levi, Ray and Shoup, Xerox and Siemens have AFP-compatible print drivers and more are expected in time.

Q: What is an 'OVERLAY' in AFP?

A: An overlay is the AFP technical term for an electronic form. This is used by the printer at the time of print to overlay the document or data being printed. It can replace the paper-form used before. Multiple overlays can be used on a single page. Overlays can be different for additional copies of the page printed.

Q: What is a 'FORMDEF' in AFP?

A: A FORMDEF is the AFP 'forms definition', which defines the parameters of the physical page environment, like the overlays and the paper bins used, as well as simplex and duplex options. FORMDEF is used on all document types.

Q: What is 'PAGEDEF' in AFP ?

A: A 'PAGEDEF' is the data formatting information for a line-print dataset or a net-data file. It is executed at the time of print, so that the net-data are sent to the spool. Therefore multiple 'PAGEDEFs' can be used with the same print file.

Q: What is a PSEG in AFP ?

A: A PSEG is short for Page Segment and is usually an image element such as a signature or a logo, but may also contain text elements.

Q: Which host components do I need to work with the ISIS Papyrus Designer?

A: Only the PSF, or alternatively Papyrus Host (and Server) are required to utilize Papyrus Designer.

Q: Can I simply code AFPDS myself and forego using any ISIS products?

A: You can do that, but it will be very time-consuming and the maintenance will require program changes for any simple forms or text change. This is much too restrictive and expensive.

Q: Can I print Postscript files on AFP printers?

A: Yes. The conversion is only possible on OS/2 or AIX using the relevant versions of PSF. The resulting AFPDS file can be sent to any AFP platform. In most cases the generated AFPDS files have a very large image content and print very slowly. The same is true for other PostScript solutions like the Entire Fibre Gateway for Xerox printers.

Q: What is SCS?

A: SNA Character String is a very old print datastream which is still used for compatibility, but most of the time in connection with Escape sequences mixed into the data to control the printer HW from the application program.

Q: Can I print Windows 3.11 documents to AFP?

A: Yes. Depending on the Windows platform, the conversion requires ISIS-supported migration.

Q: Can I print such a Windows AFP document to a Xerox Printer?

A: Yes. The Papyrus Server will dynamically create the all Xerox fonts required. Performance depends very much on the overall document complexity and the number of fonts used.

Q: How canI get the ISIS Papyrus AFP Viewer?

A: You can request a download link for the freeware ISIS Papyrus AFP Viewer here.

Q: Is the Papyrus Platform developed in the same language on all platforms?

A: Yes. Object oriented development with C++ is the key to portability and flexibility in design and for fast product enhancement. Porting is achieved by a simple recompile to the other system platforms.

Q: Does the Papyrus Platform have third-party prerequisite products?

A: No. Formatting, viewing and printing on all platforms can be done with Papyrus Host/Server/Client components. Spell-checker/hyphenation is supplied from third parties.

Q: Can other products interface with your products?

A: Yes. All fully AFP-compatible viewers, print drivers, resource generators and archive systems can interface to Papyrus through the AFP architecture. We also offer import interfaces to various source, font and image formats.

Q: Can Papyrus be used for image applications like cheque image printing?

A: Yes. The integrated image capabilities are a major strength of the Papyrus Document System. Images can be converted to IOCA and then printed at high speed with IPDS-capable printers. Image size can be controlled by the DocEXEC during the formatting process without touching the image directly.

Q: Do the documents need to be processed in any way for archiving?

A: No. DocEXEC can produce a complete archive file including index and all resources. This file can be stored to CD-ROM or to an AFP-capable archive system like AFP OnDemand. If any other archive format is required, Papyrus Server can do the conversion at time of archiving. For CD-ROM and for distribution ISIS provides a license free Papyrus AFP-Viewer.

Q: Do you have product solutions for an application merging documents into a single print package?

A: With the document formatter Papyrus DocEXEC, one formatting run can merge pages from different applications together into one print file. In this case all pages must be generated at the same time. Using the Papyrus Postprocessing functionality it will even be possible to merge pages together that have been generated at different times from different applications. The pages are stored in the PrintPool (e.g., database or file system). After the merge and sort step the OMR code or Barcode can easily be added alomg with page numbering (1 of n) if required.

Q: Can Papyrus extract variable data from a database and format via DCF?

A: Papyrus DocEXEC with the Postprocessing functions can either format from a flat file or it can directly access data from e.g., the dB/2 database on MVS or Oracle, Sybase under NT/UNIX. The use of DCF will not be required if DocEXEC is used. DocEXEC will format much faster than DCF and will output AFPDS format like DCF. To develop an application Papyrus offers a graphical design suite of tools in WYSIWYG, with no coding required.

Q: Which product can provide customized network print-outs of database driven data?

A: Papyrus Client can be used for end-user business document applications. There is no need to use a proprietary database such as Microsoft Access. The application and logic (PROMPT for data and text) is simply defined in the Papyrus Designer and executed by the Papyrus Client. The Papyrus Client can access the database directly. The user works in a completely controlled environment and can make only those changes to the document he is authorized to make. The result is an AFP document which can be printed at the desktop printer or sent for central printing to IPDS or other production printers. It is important to note that the document is not geared to a proprietary environment without upward compatibility issue but it can be printed to any printer due to the printer and platform independence of the Papyrus products , locally or centrally.

Q: Does Papyrus support image prints from an Image System to print with a group of output?

A: Papyrus DocEXEC has a full image print support. Many customers use applications for cheque image printing. The format used is IOCA and the image can be resized to the space available on the page if required.

Q: Is it essential to know the printer setup before I develop an application?

A: No. Using Papyrus the documents are generated printer-independent. At any time the choice of printer can be switched. Many vendors support different printers for AFP printing. With Papyrus Server ISIS offers AFP printing to IPDS, PCL, PostScript, Xerox MetaCode and many more. The Papyrus Print Services do the complete job without any change to the application. Only at the time of print do you decide which printer you use.

Q: Can Papyrus print cheques formatted on a mainframe to any of several remote sites around the globe on their various PC printers?

A: Papyrus customers are printing check applications centrally on IPDS. The same application is also printed in remote offices on PCL printers with 100% identical result using Papyrus Server.

Q: Which kind of databases does Papyrus support?

A: ISIS supports dB/2 on the mainframe and Oracle, MS SQL Server, and Sybase database on UNIX and WinNT.

Q: What are the minimum hardware PC-requirements for Papyrus products?

A: For design products Pentium 100MHz with 32MB minimum, for better performance 64MB are recommended. A 17" Screen with 1280x1024 resolution with 16M colors if true color applications are designed. Parallel port for test printing and hardlock-key. PCL4/5 printer with 2MB. For production machines 128MB RAM is recommended with a 300MHz CPU.

Q: Can the product enhance and format an existing print file?

A: Yes. DocEXEC was made specifically for that purpose. It therefore works very well with any ASCII or EBCDIC input file and even uses the existing channel controls to the maximum. Variables and fields are extracted from the file as defined. Unwanted data can simply be ignored.

Q: Does the product provide query and report generation capabilities?

A: No. In most cases data files exist or are created with existing database tools. These standard report files can be excellently formatted. ISIS provides DB query capabilities for dB/2, Oracle, MS SQL Server, Sybase others will follow.

Q: Does Papyrus provide internal sorting functions on the data?

A: Yes. High-speed sorting is a very specialized task. It only makes sense to use existing sort products to generate a data file for formatting. Small-scale sorting can be done directly with Papyrus DocEXEC. Papyrus DocEXEC offers now the capability to preprocess the data files to make them usable as input to a high-speed sort and then as input to DocEXEC formatting.

Q: Can Papyrus merge two data files?

A: Yes. The files are processed to have identical sort index entries on each data records and then are appended and sorted. The definition of the sort criteria and preprocessing is done within the Papyrus Designer without coding.

Q: Can Papyrus use existing cobol copybooks or MACLIB descriptions?

A: No. As the product is a true multi-platform product, such a feature has low value. It is planned to provide such a capability for the MVS version in the near future. However, in its current version it can directly use the PIC descriptions of COBOL.

Q: Can Papyrus use existing PAGEDEF field descriptions?

A: Yes. The PAGEFORMAT part can be directly used or converted to a DOCFORMAT using the same FIELD descriptions.

Resources are the fonts, logos and forms needed at time of formatting, viewing and printing to be able to generate and present the document correctly. If the correct resources are not used at time of formatting, viewing or printing, the document will not just be lower quality, IT WILL BE WRONG! Resource management is a key to quality-ensured document production.

Q: Do resources (font, forms, logos) need to be converted to internal format?

A: No. The Papyrus System uses the AFP resource formats directly.

Q: Is the resource (font, forms, logos) format standard or proprietary?

A: Standard. The Papyrus System uses the fully documented resource formats of the AFP architecture. This includes resolution-independent Adobe outline fonts. If you already have AFP resources NO CONVERSION is required. Most other resources like MS True Type and TIFF can be converted with the Font Converter.

Q: Does the developer have to maintain resource tables for different printers?

A: No. As a single resource library is used for printing to all types of hardware, no other libraries or resource formats have to be managed manually.

Q: Does resource table information have to be maintained manually?

A: No. Papyrus reads all the information required, like forms and logos sizes and character width directly from the resources.

Q: Are resource tables required for document formatting?

A: No. As the Papyrus DocEXEC also can run on a user's laptop computer, such a requirement would not be sensibly manageable.

Q: Does Papyrus support standard forms source code languages?

A: Yes. IBM OGL is the standard language, but also Xerox FDL can be converted and single document pages from most Windows products like PageMaker can be imported as forms through the Papyrus Printer Driver.

Q: Does the developer have support to deal with different resolutions?

A: Yes. Papyrus and AFP offer that support. Regardless of the use of outline fonts, the document has to be committed to a resolution at formatting. The unavoidable differences between 240, 300 and 600 dpi can be checked at development time.

Q: Does the user have to manually define all relationships between objects?

A: No. These relationships are extracted automatically from the AFP resources on import to the database. However, a query can be set up, showing in which documents a certain font, forms or text element is used. This database can also be used to build export packages for software distribution systems.

Q: Can resources be converted or generated from other formats?

A: Yes. Adobe or TrueType Outline fonts can be converted to AFP font formats. TIFF images can be converted to PSEG or compressed IOCA. Forms can be converted from FDL or from Windows products to AFP.

Q: Does Papyrus ensure that the proper resources are used for printing?

A: Yes. The AFP architecture enables this. IBM PSF and Papyrus Server dynamically control the use of resources in the printer from a single resource library. This is also done by Papyrus Server for Xerox Metacode and for HP-PCL4/5. In this manner, the operator can choose whether he wants to print the document on a 240 dpi IPDS or 300 dpi Xerox Metacode machine without reformatting the output.

Q: Does the product provide a fully documented and human-readable source code?

A: Yes. The DOCDEF is upward compatible to IBM PPFA source code.

Q: Do product-specific commands have to be inserted in our applications?

A: No. Unlike products based on markup-controls as the usual {tags}, Papyrus can use any data field as a controlling element. Proprietary control tags in the data mean that a change to another product would require a huge conversion effort. As long as the control tags can be easily identified, DocEXEC can even use existing tags of other systems as control information.

Q: Are text elements stored in a standard or proprietary format?

A: Standard. ISIS recommends to store text elements in raw ASCII or EBCDIC format. In this manner they are easily maintainable by users and can be simply reused for other systems and applications. Papyrus can be setup to accept any text control escape sequences within the raw text. DCF SGML and other formats can be supported as external text elements.

Q: Is a change in a form, graphic or text element reflected in all documents?

A: Yes. In case this element is reused in this manner, a change will propagate automatically to all documents using this element. This saves time, costs and effort for version control.

Q: Can Papyrus provide a PAGEDEF with white space removal capabilities?

A: Yes. The PAGEDEF is imported and just enhanced. The data is not changed.

Q: Does Papyrus also develop high-performance IBM OGL/PPFA source code?

A: Yes. In this way simple forms/data applications do not need to use the formatter and are just printed by IBM PSF or Papyrus Server.

Q: Can OGL/PPFA source code be imported?

A: Yes. It can be imported, edited and also later used for enhanced DOCDEF statement formatting applications.

Q: Will an OGL/PPFA OR FRM/JDE experienced person understand your coding?

A: Yes. Because it builds on these functions and expands them.

Q: Can Papyrus use the same document description on multiple platforms?

A: Yes. The DOCDEF is used by DocEXEC on all platforms like MVS, UNIX, AIX and OS/2 without change.

Q: How many separate programs are used to generate the document from the data?

A: One. Papyrus DocEXEC provides simple single-step execution.

Q: Are all these programs available across all supported platforms?

A: Yes. Papyrus is available for MVS, AIX, HP-UX, SUN Solaris, DEC Alpha, SCO-Unix, OS/2, WindowsNT, and Windows95/98.

Q: Must the printer type be chosen at the time of statement formatting?

A: No. As Papyrus does not use the usual 'emitter' or 'converter' technique, the generated AFPDS file can be printed to any IPDS, HP-PCL4/5, Xerox Metacode, and Postscript printers at the operators choice. The same file can be archived or distributed for viewing with the Papyrus Client to PC platforms.

Q: Does Papyrus provide indexing for archiving, i.e., ACIF compatible?

A: Yes. The ACIF index is also used for previewing to locate pages in a large spool file and not just for archiving purposes.

Q: Does Papyrus provide ACIF group indexing?

A: Yes. Papyrus DocEXEC provides fully qualified group index names from variable expressions.

Q: Does Papyrus support multiple paper input bins on cutsheet printers?

A: Yes. Each sheet can have its own paper bin.

Q: Does Papyrus support differing paper sizes in a single run?

A: Yes. Each sheet can be defined separately.

Q: Does Papyrus support multiple logical pages per sheet?

A: Yes. Any number of pages in any direction and sequence.

Q: Does Papyrus support duplex and booklet modes?

A: Yes. Normal and tumble duplex and booklets with any number, orientation and sequence of logical pages per finally folded sheet.

Q: Can postprocessing OMR or barcodes be inserted?

A: Yes. Any type can be created either through fonts or by graphics.

This is not a complete listing of functions, but just an assembly of questions that relate to the functional capabilities.

Q: Does Papyrus support spot color?

A: Yes. Up to eight spot colors can be used.

Q: Does Papyrus support full color?

A: Yes. You can generate full-color objects like charts, images and text from the input data and Papyrus supports full-color PostScript printing.

Q: Can forms be used and freely positioned in the flow of the statement?

A: Yes. Forms can be used tied to a logical page or as an element in the flow of the document. In this case the form is a building block, which will break as a whole to the next page, including the related data fields if so defined.

Q: Can images, like logos and signatures, be positioned freely and on forms?

A: Yes.

Q: Can images or forms be called by name in a data field?

A: Yes. In this manner scanned images from an archive can be called in and printed with the flow of the document. This can be used for example for transfer slips with bank statements or for printing insurance claims with scanned documents attached.

Q: Does the product support substitution tables for data fields?

A: Yes. Multiple tables can be defined and reused across several documents.

Q: Can tables be defined and can they break across pages?

A: Yes. The page breaking is user-definable.

Q: Is the number of named variables limited?

A: No. It is not required to name data elements or arrays of repeated printlines.

Q: Can open-ended arrays of data be used?

A: Yes. Repeated records using the same data structure can be handled as an array.

Q: Do all variables have to be named and defined in length?

A: No. If fields are printed directly when read, no names have to be defined. With the use of delimited variables the length is flexible.

Q: Is conditional IF/THEN/ELSE logic supported?

A: Yes. Any command in the DOCDEF can be executed based on the result of such a condition. Such IF/THEN/ELSE structures can also be nested.

Q: Can macros or sub-routines be defined and reused?

A: Yes. DOCFORMATS are such sub-routines, Global and reusable DOCFORMATS are possible.

Q: Is the use of a variables limited to data fields?

A: No. Variables can be freely used for control purposes and even for positional data. All values used in DocEXEC can be formula expressions with variables.

Q: Can string functions be executed for variable data fields?

A: Yes. The usual string functions can be performed, like concatenate, truncate, left/right substring, suppress leading/trailing blanks or pad strings.

Q: Can mathematical functions be performed on data variables?

A: Yes. Addition, subtraction, multiplication and division can be used to calculate results in simple formulas, including bracket execution.

Q: Can text also be extracted and formatted from the data file?

A: Yes. DocEXEC does not distinguish between the data and the document description in the formatting process.

Q: Can fonts, images, forms and text be selected based on criteria?

A: Yes. The content or length of a data variable can be used for conditional execution of any statement element.

Q: Can diagonal or curved lines and boxes with shading be used?

A: Yes. For performance reasons (image generation), these are executed with forms elements, which can be selected and placed dynamically as required. Rules in all styles are done dynamically.

Q: Can the page orientation be changed dynamically?

A: Yes. Several LOGICAL PAGE LAYERS using different orientations can be defined for one SHEET and they can be used based on conditional execution.

Q: Can a single data record produce several pages?

A: Yes. The related variables can be reused many times and also a single variable can be split or positioned as many times and formats as required.

Q: Can subtotals for a page be calculated?

A: Yes. For a table or repeated variable structure a SUBTOTAL command is used.

Q: Can bar, line and pie charts be produced dynamically from input data?

A: Yes. Many chart types in 2D and 3D are available.

Q: Can fonts be used in all rotations and orientations?

A: Yes. The formatting automatically handles these functions through the AFP bounded box font information even for raster fonts to a Xerox printer.

Q: Can text be printed at angles or along curves?

A: Yes. DocEXEC supports any angle for OUTPUT fields and each character can be positioned specifically along a curve.

Q: Can text be printed shaded or inverted without a special font?

A: Yes. The font used by the text is processed internally and placed accordingly.

Q: Does the product support Barcode and OMR printing?

A: Yes. Any OMR and all generally used barcodes are supported including 2D Datamatrix codes. Expandable to any format.

Q: Does your product provide a PC-based graphical development tool?

A: Yes. Papyrus Designer suite is available for Windows95/98, WindowsNT and for OS/2. It shows the result of the actual data and the defined DOCDEF formatting in a 100% DOT-accurate display window (WYSIWYG).

Q: Is the design tool a single integrated product?

A: Yes. Only the true forms, fonts and image design are done separately with the OverView AFP-Designer and Font and Image Editor, if required.

Q: Can the design tool deal with any statement size and complexity?

A: Yes. It is limited only by hardware.

Q: Does the design tool use the same resources as the formatter and the printer?

A: Yes. The same AFP resource library is used. The capability to define the DOT positions is useless if it is not truly presented on the screen and can only be verified by a test-print on the actual printer!

Q: Does the design tool provide PC test printing?

A: Yes. Any modern PC laser printer can be used for test printing (e.g., PCL4/5).

Q: Is accuracy achieved by the developer manually matching the resources?

A: No. Just a single resource AFP resource library is used.

Q: Is the complex logic of the document visually presented or just in source?

A: Visually. A tree-style structure is used to SHOW AND EDIT the logic. This self-documenting window is not to be confused with what other products offer as just display functions.

Q: Does the users have to learn any language syntax to use the product?

A: No. As the editing is visual, syntax knowledge is not required.

Q: Can a well trained end user use your product?

A: Yes. If the user can code a MS Word document in 'reveal mode', showing and using all the hidden control statements or a Word macro, he/she can also use the Papyrus Designer after some training. Somebody with only text editing experience will not be able to develop an application.

Q: Can end-users maintain application text?

A: Yes. If simple 'raw text' elements are used and called into the DOCDEF, the user does not have to deal with the logic of the document and can maintain the text as needed. The design tool would not be used for that, but just a text editor. For complex texts Papyrus Client with build-in WYSIWYG Text-Editor is also available for end users.

Q: Does the design tool set also enable the development of OGL/PPFA applications?

A: Yes. The resources like OVERLAYS and FORMDEFs can be shared with the statement formatting process.

Q: Can form overlays be edited with the document visible as template?

A: Yes. For the PAGEDEF this has been available for many years. For the DOCDEF design process this will be available in the future.

Q: Does Papyrus provide a total solution for SAP business documents?

A: Yes. Papyrus develops rapidly impressive documents that are easy to read from SAP data.

Q: Can printing of SAP Documents take place on any platform and printer through Papyrus?

A: Yes. Printing can take place on any platform with the printer of your choice, e.g., IPDS, Xerox MetaCode, PostScript or PCL printers. They can be on Mainframe or Server platforms, channel attached or in the LAN. Papyrus Print Services handle the conversion of the application to the target printer transparently and without manual intervention at the time of print.

Q: Can Papyrus support bundling and merging of pages from SAP with other document applications?

A: Yes. Bundling and merging of pages from SAP with other document applications is fully supported to optimize mailing operations and postal discounts.

Q: Does Papyrus support archiving and distribution?

A: Yes. With Papyrus archiving, viewing and distribution are available in a variety of media: TIFF, AFP, GIF and PDF including CD-ROM and the Inter/Intranet.

Q: Which SAP data can Papyrus use?

A: Papyrus supports SAP R/2 data from MVS, OTF/GOF from SAP R/3 and the new SAP R/3 RDI (Raw Data Interface).

Q: Can Papyrus create a dynamic chart from the SAP input data?

A: Yes. Papyrus can generate a dynamic chart from the input data. The product supports spot color and full color.