Difference between revisions of "Color Management Planning"

From Inkscape Wiki
Jump to navigation Jump to search
Line 56: Line 56:
The algorithm for Gouraud shading is in many books on computer graphics.
The algorithm for Gouraud shading is in many books on computer graphics.


Tav: There should be no need to write out meshes as triangle meshes or in rendering them. PostScript (Level 3) and PDF already directly support mesh gradients.
<span style="color:darkred">Tav: There should be no need to write out meshes as triangle meshes or in rendering them. PostScript (Level 3) and PDF already directly support mesh gradients.</span>


'''TODO:'''<br>
'''TODO:'''<br>

Revision as of 15:22, 3 June 2021

Overview

This plan, developed by Bryce Harrington, defines how print services functionality could be added to Inkscape. This would include strong CMYK support, a Pre-flight checking feature, and improved PDF version support, among other things.

The overall effort is broken into several discrete projects that can be undertaken semi-independently. Some of the projects will need to wait until post-1.0 for landing in the Inkscape codebase, but prototypes and code targeting Inkscape dependencies like Cairo and Pixman can be landed independently of Inkscape's release schedule.

Background

For Inkscape, "CMYK support" has been a frequent request by end users, needing some degree of color management for PDF export. Naively this might sound trivial - just add support for one more way to enter color values. Indeed, Inkscape already has a CMYK tab in the Fill and Stroke dialog for doing this. Inkscape's also been able to output SVG files with "icc-color(...)" paint components[1] for several years now.

However, under the hood the CMYK tab just blindly converts the values into RGB using an algorithm that might not match what printers would do. And while the icc-color(...) capability has enabled interoperation with Scribus for importing color-managed SVG files, many have considered that workflow to be overly cumbersome. So while it is technically possible to do color management in Inkscape more or less, what users really want goes much deeper and more sophisticated, as Jon Cruz wrote back in 2009 (http://codewideopen.blogspot.hr/2009/12/inkscape-should-not-support-cmyk.html)

Professional printing is more rigorous than desktop printing, requiring tighter management of colors, fonts, transparency, blur, and so on. Close adherence to PDF file format standards is also needed. While a very diligent and knowledgeable user might be able to check their document and make the corrections manually using Inkscape's existing functionality (and perhaps sister software like Scribus), many other users will benefit from having more guidance - and for having the software perform the necessary corrections for them.

A common workflow used in other graphics software is to launch a graphical "pre-flight checker" that analyzes the document and allows the user to decide how to handle issues. We will follow a similar approach with this design, while recognizing that there is an important balance to strike between giving the user a high degree of control and overwhelming the user with too much choice.

Changes are also required under the hood, such as improvements to PDF generation, restructuring how colors are managed internally, and fallback logic for converting SVG elements into what can be supported in particular PDF formats.

Needless to say, this all encompasses a large amount of work, well beyond the "typical" Inkscape feature. We'll need to look at how we can split it up into more digestible chunks.

Broadly, there are several ways to divide out the work.

First, tasks can be divided into implementational lifecycle:

  • A. Research & Prototyping
  • B. Main development
  • C. Final Polish
  • D. Maintenance

Second, tasks can be split by the feature area they affect:

  • A. Color management
  • B. Font embedding
  • C. Rasterization of unsupported SVG features
  • D. PDF version conformance checking/correcting

Third, tasks can be split up by what parts of codebases they focus on:

  • A. Changes to Cairo's dependencies (Pixman, Pango, etc.)
  • B. Changes to Cairo
  • C. Changes to Inkscape's backend code
  • D. Changes to Inkscape's frontend (GUI and dialogs)

As each of these areas draws from distinctly different programming skillsets, we'll divide the development steps into discrete projects organized along these lines.

Add support to Cairo for exporting mesh shading to PDF

Cairo already supports rendering meshes to bitmaps, which we already use in Inkscape. But what's needed is an ability to export Type 6 (Coons patch) meshes to PDF/PostScript.

The Type 6 shading is a special case of the Type 7 (Tensor-Product patch mesh) shading so only implementing Type 7 may be all that is required. Inkscape already supports type 7, but it's not user accessible currently, just for testing purposes.

One possible solution would be to create a triangle mesh (similar to Type 4 shadings) from the Type 7 patch mesh and shade the triangles using Gouraud shading.

The Poppler source may be used to get an idea how Poppler renders these gradients. However the approach Poppler uses of recursively breaking each patch into smaller patches then filling the tiny patches with a solid color is not appropriate for cairo due to the visible seams between patches due to antialising.

The algorithm for Gouraud shading is in many books on computer graphics.

Tav: There should be no need to write out meshes as triangle meshes or in rendering them. PostScript (Level 3) and PDF already directly support mesh gradients.

TODO:

  • Links to the bits of Cairo/Poplar code mentioned above
  • References for mesh shading types + algorithms

Codebase: Cairo
Skills: C Programming
Difficulty: Hard
Dependencies: None
Proposer: bryce
Deliverables:

  • Proof-of-concept patchset
    • For prelim review / course correction
  • Patchset against Cairo master
    • Functional implementation
    • Test cases for Cairo testsuite
    • Doxygen comments for new internal/external APIs
  • Demonstration program
  • Explanation of functionality
    • One or more blog posts, or a patch to cairo-www

Update Cairo to support PDF 1.6

Inkscape will need to support a variety of different print export formats.
Three common ones are:

  • PDF/X-1a
  • PDF/X-3
  • PDF/X-4

Other formats exist, but there has been industry standardization around these three so focusing on them would make sense. Of the three, PDF/X-4 is the only one that supports transparency, and thus would be vital to have supported, but PDF/X-3 may be a more realistic initial target.

Each of these formats has somewhat different requirements, which will have to be checked as part of a preflight process.

PDF/X* are published ISO standards but aren't freely downloadable, however some are available on the Adobe website, and some offers of assistance in getting them have been made -- contact Bryce for points of contact. They might also be available from a college or university library.

According to Cairo's documentation for cairo_pdf_version_t, it appears to support only PDF 1.4 and 1.5. PDF/X-4 is built on PDF 1.6.

Note that PDF 1.7 and PDF 2.0 specs have been released by ISO, and would be logical follow-on projects.

  • Review Cairo's codebase to verify it adequately supports PDF 1.5, and if not identify discrepancies. (Some PDF features like 3D, forms, etc. don't apply to Inkscape).
  • Review the PDF 1.6 spec to identify functional differences between PDF 1.5 and 1.6.
  • Implement patches to add PDF 1.6 support to Cairo.

TODO:

  • Lookup what's different in the newer standards. Are they significantly stricter/harder to implement?
  • Reference earlier Cairo patches that added PDF 1.5 support

Codebase: Cairo
Skills: C Programming
Difficulty: Hard
Dependencies: None
Proposer: bryce
Deliverables:

  • Proof-of-concept patchset
    • For prelim review / course correction
  • Patchset against Cairo master
    • Functional implementation
    • Test cases for Cairo testsuite
    • Doxygen comments for new internal/external APIs
  • Demonstration program
    • Generates PDF 1.6 output files showing various PDF 1.6 features
  • Explanation of functionality
    • One or more blog posts, or a patch to cairo-www

References:

Add HDR image surface type to Cairo

The new image format will implement the scRGB colorspace[2]. This involves writing code for Porter-Duff[3] compositing on the new format and making Cairo use them. Optionally, another (better but more involved) approach might be to extend the Pixman library to support the new format, and plumb in support for it in Cairo.

The color format to target should probably be RGBA64, for consistency with OpenGL/Vulkan, although note that previous discussions[3,4,5] of supporting HDR in Cairo have assumed ARGB64.

Conversions between the 16-bit floats used by colour spaces such as scRGB and 32-bit floats should use the algorithms explained in Jeroen van der Zijp’s Fast Half Float Conversions[6].

TODO:

  • A few links to references for specialized terms
  • Reference to other codebases implementing HDR

Codebase: Cairo, Pixman
Skills: C Programming
Difficulty: Medium
Proposer: bryce
Deliverables:

  • Proof-of-concept patchset
    • For prelim review / course correction
  • Patchset against Pixman master
    • Functional implementation
  • Patchset against Cairo master, with the modified Pixman
    • Functional implementation
    • Test cases for Cairo testsuite
    • Doxygen comments for new internal/external APIs
  • Demonstration program
  • Explanation of functionality
    • One or more blog posts, or a patch to cairo-www

References:

Implement Color Management API for Cairo

In order for inkscape to produce CMYK Postscript and PDF files, Cairo needs support for other color spaces[1]. Cairo currently has several ways to accept color information (e.g. cairo_set_source_rgb), but we need a method to associate with Cairo surfaces that follows ICC standards and permits specification of input and output color formats, and a way to transform from input to output.

Thankfully, this does not need to build from zero. Deep design work has been done for Cairo in the distant past to create a well-thought out and well-documented API plan[2], and there has been some preliminary experimentation work[3] and a second effort to implement it more formally[4]. (Franz Schmid apparently also wrote CMYK/Spot Color patches for Cairo, but it's uncertain where these are[5].)

Unfortunately the patches did not land in trunk, and the effort appears to have ceased long ago. But, the needs of today are essentially the same as they were then, so presumably the approach that was worked out back then would still make sense today and is worth dusting off and revisiting. The plans may need some refinement and/or rework, both to update it to the current state of the art, and to incorporate additional requirements we need for Inkscape.

Suggested initial activities:

  • Rebase Adrian Johnson's color-space patchset to current Cairo trunk, to facilitate review/testing of it, and to potentially carry its development forward.
  • Thoroughly review past Cairo work in this area, including specs [6,7,8] (see References)
  • Review other FOSS codebases that implement color management for additional ideas, including Scribus' PDF library (pdflibcore) and PoDoFo (http://podofo.sourceforge.net)
  • Using past work, derive an updated plan for the API and its implementation.
  • Contact past Cairo developers who have worked on color management to solicit advice and feedback on the plans.
  • Revise / expand on ajohnson's color-space patchset to cover one display backend that Inkscape uses (i.e. choose one of xcb, win32, or quartz)
  • Define what someone would need to do to implement support for the remaining supported Cairo backends.

TODO:

  • Have someone compile a report/implementation plan in preparation for this. Basically read the dissertation and create a task list of what needs done.
  • Would be useful to break this job into one or two more jobs to spread out the risk and labor a bit.

Codebase: Cairo
Skills: C Programming
Difficulty: Hard
Dependencies:

  • "Add HDR image surface type to Cairo/Pixman"

Proposer: bryce
Deliverables:

  • Proof-of-concept patchset
    • For prelim review / course correction
  • Patchset against Cairo master
    • Functional implementation
    • Test cases for Cairo testsuite
    • Doxygen comments for new internal/external APIs
  • Demonstration program
    • Generate output images with different color spaces for comparison
  • Explanation of functionality
    • One or more blog posts, or a patch to cairo-www

References:

CMYK Color Profile Loading and Embedding GUI

Printing companies will provide a color profile, such as "ISO Coated v2 300% (ECI)", that is provided as a file that the user will download and install to a directory on their system.

This project aims to provide GUI support for loading files from this directory, and allowing the user to select and load one that will then be associated with their SVG file and used when generating the PDF.

There are several swatchbook input formats that will need to be loadable. For example, ACB (Adobe Color Book), ASE (Adobe Swatch Exchange), AI, SBZ (Swatchbooker's native XML format)[1]. Support for ASE or SBZ will provide access to hundreds of CC-licensed LAB values, so either of those could be a good initial focus. See Scribus and Swatchbooker for example FOSS implementations to derive ideas from.

Then there are also palettes such as Pantone and 'GIMP Palette (GPL)'. Getting Pantone color palettes will be difficult/expensive, and may need to be obtained (by the user?) from a proprietary application. GIMP Palette is limited and will be of lesser interest though. A better option might be to look at the GPL versions of the CIELAB and CIEHLC palettes from freieFarbe/freeColor[2,3]. The HLC palette provides a truly FOSS alternative to Pantone, and is already used by LibreOffice.

CxF3 is a new ISO standard (See: https://www.xrite.com/de/page/cxf-color-exchange-format). CxF3 files can store palettes of multiple color models, as well as spectral colors. Scribus supports this standard already.

TODO:

  • How does this interrelate to Inkscape's existing palette loading support? Does this affect the color bar?
  • Is there any backend work needed to support this? If so, is that worth doing as a separate job, or as part of this one?
  • Should mockups be done of the GUI?
  • Could sample color profiles be collected as a separate task?
  • Could the color palette loaders be put into a reusable library?

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Medium
Proposer: bryce
Deliverables:

  • Selection of representative sample color profiles input files for testing
  • Branch against Inkscape master
    • Functional implementation
    • Test cases for Inkscape testsuite
  • User Documentation
    • How does one get a color profile?
    • Given a color profile, what are the steps to take to associate it with an SVG file?
    • What are some potential problems to expect, and how to deal with them?

References

Color Coding GUI

This project implements a GUI that helps the user convert colors in a document to CMYK equivalents, spot colors, and CIELAB.

The tool scans the SVG document and builds a listing of all colors, excluding ones that are in the palette but not used by drawing elements. The user can then type in meaningful names for each of the colors, and optionally associate the color with a predefined CMYK color or spot colors from a color book, or accept an autoconverted value.

Ideally, this color mapping would be handled through CSS classes, which may require some improvement to CSS handling (see Tavmjong for guidance).

In addition to naming existing colors, the user will need a way to directly input new LAB colors, that can be stored in the SVG file using the methods provided by the SVG specification.

Large quantity of colors to convert is an important use case, and the tool should provide various ways to help the user quickly process a lengthy list. Some examples might be: Macros; controls to tweak the autoconversion algorithm; import color processing logic from another document; etc.

Part of this effort includes reworking or removing the CMS tab, and/or changing the design layout of the CMYK tab. It should also include a mechanism to designate a global CMYK profile for documents, such as a widget in the Document Preferences dialog that sets a global context.

Googling for "inkscape cmyk dialog" turns up some mockups and other interesting stuff worth looking at.

TODO:

  • Is there any backend work needed to support this? If so, is that worth doing as a separate job, or as part of this one?
  • Add a link to a reference for the section of the SVG spec covering color management for LAB colors.
  • Rename to "Convert Colors" ?
  • More design needed for what the feature should actually do, the current description is vague in too many places.

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Medium
Proposer: bryce
Deliverables:

  • Selection of representative SVG documents with various color combinations for testing
  • Branch against Inkscape master
    • Functional implementation
    • Test cases for Inkscape testsuite
  • User Documentation
    • Describe workflow for converting a document's colors
    • Identify tricks for converting especially large numbers of colors
    • Explain what each widget in the GUI does
    • Explain how the autoconversion algorithm is designed to work

References:

Support Cairo-based Color Management in Inkscape

Once the color management API is landed in Cairo, implement internal support in Inkscape to make use of it.

Internally Inkscape's operations are largely colorspace neutral, however it does assume use of device-dependent Red-Green-Blue-Alpha (RGBA) data for representing color information (SVG is defined in terms of sRGB and linear RGB, and performing SVG rendering in a non-RGB colorspace probably doesn't make sense), and some parts of the codebase currently depend on this assumption. Unfortunately, while RGB is a common standard for graphical displays, it is device-dependent and lacks the gamut of other color formats. CMYK is also a device-dependent format, so "switching" to CMYK internally wouldn't be a sensible solution. The CIELAB color space is designed to be device-independent and to represent colors in a perceptually uniform manner; it expresses colors as L*, a*, b* components (Lightness, green-red, and blue-yellow).

This project requires, in addition to hooking up to the Cairo color management APIs, making adjustments to Inkscape's internal color handling support. This may include increasing the bit depth that colors are represented, changing blending operations to be in linear RGB space, and/or similar.

There is a set of "color-interpolation-*" CSS properties that controls the space in which interpolation should be performed, and we should just implement handling for these properties. For example, gradients interpolated in linear space actually look very non-linear if the endpoints have significantly different luminance.

TODO:

  • There is also no need to convert to CIELAB, unless there is some special transformation that requires that space.

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Hard
Dependencies:

  • Color Management API for Cairo
  • CMYK Solid Color Profile Embedding into PDF

Proposer: bryce
Deliverables:

  • Branch against Inkscape master, with modified Cairo
    • Functional implementation
    • Test cases for Inkscape testsuite
    • Doxygen for added internal/external APIs
  • Set of sample input SVG files that demonstrate the color management support in various ways.
  • Step-by-step walkthru of how to test out the feature and verify correctness of the implementation.
  • Developer Documentation
    • Blog post, detailed email, or similar explaining the effects of these changes, as it relates to Inkscape development.

Font Embedding for Print

Implement routines to perform several different types of adjustments to fonts used in an SVG document.

First, fonts can be either embedded or non-embedded. Implement a routine to convert specific fonts in the document between these states.

Second is a mechanism for embedding a subset of a given font. Certain fonts are full-featured and thus would cause the PDF to be extremely large, so embedding only the portions in actual use makes sense. This should be tested especially with CJK fonts as they tend to be quite large and thus in high need of this capability.

Only Postscript, TTF, and OTF fonts are supported in PDFs. Other kinds of fonts, such as SVG fonts, exist but are not widely used nor supported; this task should focus itself on commonly used types of fonts.

TODO:

  • For embedding fonts in SVG, we should support only the WOFF format in a data href attribute. "SVG Fonts" are inherently broken and deprecated, they should not be used.
  • This project actually has three parts, in the following order:
    1. Embedding a font in SVG
    2. Exporting a document containing an embedded font to PDF
    3. Embedding a subset of a font in SVG – I don't think the current PDF exporter will magically know how to handle these embedded fonts.

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Medium
Proposer: bryce
Deliverables:

  • Branch against Inkscape master
    • Functional implementation
    • Test cases for Inkscape testsuite
  • Step-by-step walkthru of how to test out the feature and verify correctness of the implementation.
  • Developer Documentation
    • Explain the font embedding process in a blog post or similar.
    • Identitfy possible follow-on work
    • List potential issues to expect from odd fonts, and give some guidance on how they could be dealt with.

Prototype PDF Pre-Flight Checker Script

Write a command line tool that takes an Inkscape SVG document and performs a selected set of PDF standards checks on it.

The purpose of this prototype is to research and demo pre-flight checking. It should help us gather ideas of what checks need to be run and how they could be implemented, to create working proof-of-concept code that others can use as a conceptual reference, and to identify other development projects that may need to be undertaken for the overall effort. Attention should focus on the PDF checks themselves and algorithms for processing the document, not on end user usage nor how it should relate to Inkscape; this is a prototype and will eventually be fully reimplemented in C++ with a native Inkscape GUI, so this is intentionally going to be sketchy. Some functionality may be far too difficult to do in python or to do externally from Inkscape; it is acceptable if these areas are left stubbed in with mock functionality to demo what could happen.

The process of preparing a document for print is termed "Pre-Press", and involves both manual checking your document, and automated checks, in addition to other steps to actually generate the PDF file and package it for sending to the printer. The automated checking portion of this workflow is termed "Pre-Flight", and is what this project focuses on.

The tool's input should be a filename of an SVG file produced in Inkscape 0.92.x, and the PDF standard to be verified against. Command line options should allow enabling/disabling of other checks, selection of which layer(s) to process/ignore. The tool's output should be a parseable structured text listing (e.g. JSON or YAML) of checks performed with a pass/fail indicator, and a textual suggestion for what the user should do to correct it.

The provided SVG file will need to be parsed into its graphical elements, but the tool won't be expected understand much of the scene context. For instance, it will be able to detect if shapes have gradients or transparency, but will not know if the shapes overlap.

Thus, the breadth of checks it can perform will be limited, but as this tool is being developed and tested collect ideas for more sophisticated checks that could be done. Assembling this collection of check ideas will be a key deliverable for this effort.

Actual generation of PDF files is outside the scope of this prototype,unless it would be useful to generate a PDF to inform the testing. It is acceptable to run the Inkscape executable to do this generation, using Inkscape's command line arguments. Since under the hood Inkscape's PDF code uses Cairo, it is also acceptable to do PDF generation through pycairo or similar, if desired.

Codebase: None
Skills: Python Programming
Difficulty: Medium
Dependencies: None
Proposer: bryce
Deliverables:

  • Code:
    • git repository containing the python code for the tool
    • Test input files
    • Example output data
  • User Documentation
    • Basic usage docs (printed when run with '-h' flag
  • Developer Documentation:
    • Research notes collected during development.
    • Speculative ideas on how a future implementation could do this even better, written as blog post(s), emails, or similar.

References:

Checker/Corrector C++ Core Code

Within the Inkscape codebase, implement the core classes and data structures for document checking, thus laying the core of Inkscape's future 'export for print services' capabilities. Similar code exists in Inkscape for style and attribute checking, and may be worth building upon - see Tavmjong for details.

This fully reimplements the earlier python prototype in C++ using Inkscape's codebase and adhering to Inkscape's coding standards and practices. It should go beyond the earlier checker both by implementing deeper checks and also by providing mechanisms to correct the document. For example, if the desired PDF format does not support gradients, it could recommend three solutions: a) Replace gradient with a solid color, b) change the single shape into a set of N shapes each with a color selected from the gradient, or c) render the shape into a raster image to insert in place of the gradient-using graphic.

This code takes as input a 'document descriptor' and a 'preflight profile' data object, and provides algorithms to analyze the document's transparency, filters, blend modes, colors, fonts, image resolution, ink coverage, and other aspects of PDF version compatibility. The document descriptor provides access to the internal representation of the vector document, along with indicators of which layer(s) are to be analyzed and other document settings. The preflight profile collects a variety of options to control which checks are done and how to deal with failures.

For output, the checker creates a data structure containing the analysis results. Each result has a pass/fail indicator, and for failed items it includes zero or more 'Correction' objects, one of which is marked as "default" for that set.

A 'Corrector' routine is implemented by this project. This routine takes as inputs a set of 'Correction' objects to apply to an SVG document, converting fonts, transparency, colors and other elements in it according to its rules, to produce a modified SVG ready to be passed to the PDF exporter. (Since this will likely result in destructive changes to the original SVG, an approach might be to create an in-memory copy of the SVG, run the Corrector on it, and then send the output SVG directly to the PDF exporter; if the user wished to export for several PDF versions, or with several different export options, this would let them keep the source SVG pristine.)

TODO:
I'm not sure about developing something in an extension and then integrating it into core. Historically this hasn't been very successful - if something is created as an extension, it tends to stay an extension. Might be a better idea to do this in C++ from the start.

I think the project description is focusing too much on low-level mechanics, and is too vague about what specific kinds of corrections should be implemented.

The general idea of fixing a document for export by modifying it is IMO not great. (By the way, I'm also fairly convinced by now that keeping parallel XML and SP trees is wrong; instead, XML should be generated on the fly from SP when saving, with consistency of this transformation verified by unit tests.) We should treat different PDF flavors as alternate serialization formats, not as sets of changes necessary to make the document compatible.

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Hard
Dependencies:

  • "Prototype PDF Pre-Flight Checker"
  • "Add support to Cairo for exporting mesh shading to PDF"
  • "CMYK Solid Color Profile Embedding into PDF GUI"
  • "Color Coding GUI"
  • "Font Embedding for Print"

Proposer: bryce
Deliverables:

  • Branch off of Inkscape master
    • Code implementation
    • Test cases for Inkscape testsuite
    • Doxygen for added internal/external APIs
  • Unit tests providing coverage of the core code, each checker, and each corrector.
  • Developer Documentation:
    • Doxygen documentation for all non-internal routines
    • How to add new checks and corrections

Pre-flight Checker GUI Dialog Mockup

Design GUI dialogs for the pre-flight analysis.

Take a holistic view of the workflow that users will follow to prepare their documents for professional printing. What decisions should they be expected to make? What information do they require to make those decisions? What do print services expect and what will best match their level of knowledge?

Create graphics displaying the visual elements users will interact with to prepare their documents for printing. Show several conceptual drawings of graphical interfaces in various relevant states. How could the preflight GUI be laid out? Which toolbar(s), menu(s), and/or dialog(s) should have actions to open the pre-flight gui? What should the icon look like? What terminology should be used for the menu item?

TODO:

  • Not sure about the whole "pre-flight" terminology, we should avoid jargon if possible. It could simply be called "Check for Printing Problems" or "Prepare for Printing".

Codebase: Inkscape
Skills: Design, Usability
Difficulty: Medium
Dependencies: "Prototype PDF Pre-Flight Checker"
Proposer: bryce
Deliverables:

  • Mockup
    • Vector graphics images
    • Glade layout files (where feasible)
    • Step-by-step walkthru of how to test out the feature and verify correctness of the implementation.
    • Documentation:
      • Usability analysis report
      • Explain the workflow(s) the users would follow
      • Explain what each widget in the GUI would do

Pre-flight Checker GUI

The preflight GUI is accessed by the user when they are ready to do print production work.

From this GUI they can start the analysis, and then review its findings once complete. Fixable items will be marked as such, with appropriate GUI controls to let the user request fixes for selected (or all) issues.

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Medium
Dependencies:

  • Checker/Corrector C++ Core Code
  • Pre-flight Checker GUI Dialog Mockup

Proposer: bryce
Deliverables:

  • Branch against Inkscape master adding the feature
    • Code implementation
  • User Documentation:
    • Describe workflow for running the checker GUI
    • Explain what each widget in the GUI does
    • Explain what each result means
  • Step-by-step walkthru of how to test out the feature and verify correctness of the implementation.
  • Developer Documentation:
    • Speculative ideas on how a future implementation could do this even better, written as blog post(s), emails, or similar.

Export for Printing GUI

The process of finalizing a document to send for print is termed "Pre-Press". One of the substeps of this process is automated checks/corrections; this is termed "pre-flight" and addressed in some of the other proects. But there are additional steps beyond these which are manual or need more direct involvement from the user.

This project aims at providing a user interface for these other steps. This includes bleeds, reg-marks, etc. It also needs to provide a preview image and/or thumbnail to give rapid feedback to the user for their changes before making potentially destructive changes to their document.

TODO:

  • How will the selected bleeds/reg-marks/etc. be stored in the source SVG file?

Codebase: Inkscape
Skills: C++ Programming
Difficulty: Hard
Dependencies:

  • Pre-flight Checker GUI

Proposer: bryce
Deliverables:

  • Branch against Inkscape master adding the feature
    • Code implementation
  • Step-by-step walkthru of how to test out the feature and verify correctness of the implementation.
  • User Documentation:
    • Describe workflow for running the export GUI
    • Explain what each widget in the GUI does
  • Developer Documentation:
    • Summary of the feature with pointers to docs and references

Users Documentation

This writing project is to create a useful and informative end-to-end guideline for creation of professionally printable PDF documents to Inkscape.

While users of color managed PDF generation will range from neophyte to professional print expert, the audience for this document will aim for addressing the latter's needs, which will be more comprehensive.

Licensing for the delivered document must allow for use under GPLv2, GPLv3, and the Creative Commons Attribution 4.0 licenses, however the author will retain copyright ownership of all portions they write themselves; this means they may publish these portions under additional licensing terms as they desire, including commercial publication.

Formatting of the documentation should follow Inkscape's other documentation (e.g. DocBook, Booktype, etc.) A different format may be acceptable - seek direction from the inkscape-docs@ mailing list first.

This will be delivered as a stand-alone document, but the ultimate intention is to integrate it into Inkscape's official documentation[1], thus licensing and formatting need to be compatible with these existing efforts.

Codebase: None
Skills: Technical Writing
Difficulty: Hard
Dependencies:

  • Pre-flight Checker GUI
  • Pre-press GUI

Proposer: bryce
Deliverables:

  • Doxygen/Booktype file(s) with user documentation
  • List of any questions/observations for followup work

References:

Further Reading

Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=Color_Management_Planning&oldid=120167"