search

OpenOrienteering / mapper

OpenOrienteering Mapper is a software for creating maps for the orienteering sport.
https://www.openorienteering.org/apps/mapper/
GNU General Public License v3.0
397 stars 106 forks source link

Screen frequency (LPI) for print #1315

Open Andreasox opened 5 years ago

Andreasox commented 5 years ago

This issue is to understand if anyone in the Mapper community have specific LPI (https://en.wikipedia.org/wiki/Lines_per_inch) knowledge for the print workflow of today, especially for color laser prints. As high LPI as technically possible is really important for thin lines and in ISOM2017 especially for form lines.

Screen frequency (LPI, setscreen) values seems today most often to be ignored/over-ridden by the print RIP and/or the print device itself, see eg. https://support.hp.com/my-en/document/c02626902 If printing a PDF from Acrobat, the standard setting for color composite is 60 LPI and this cannot be changed. Windows10 seems to have a higher LPI than earlier versions etc.

To my knowledge you cannot set LPI interactively in any current software when printing a color composite. Thus, I assume (need to test) that when printing from Mapper, LPI is set completely out-of-control for Mapper.

I and Christer Carlsson (IOF) are discussing/checking/testing this and plan to describe the current situation in a technical memo. Any input is valuable.

I do not understand why only OCD import/export is discussed in https://github.com/OpenOrienteering/mapper/pull/1152 as screen frequency should influence all output incl. print.

dg0yt commented 5 years ago

I do not understand why only OCD import/export is discussed in #1152 as screen frequency should influence all output incl. print.

This is easy to explain: #1152 was a set of changes with the intention to preserve the relevant attributes in OCD files. It does not make assumptions about the use of these properties. However, ISOM used to define such values in the past.

I don't see how I could pass this into cross-platform (Qt) or native (Windows, Linux, macOS) programming interfaces. Howevere, there might be ways to define this in PDFs for some color models such spot colors.

Given the changes in printing and in IOF's standardization on map printing, I doubt that there is significant value in handling this explicitly.

With regard to contour lines, note that it needs halftoning of two colorants in CMYK printing. Together with the tiny line width, I assume that needs a high screen frequency to achieve sufficient sharpness for curved lines in CMYK printing. In addition, it is my impression that overprinting (simulation) mitigates some related issues, due the "darkening" nature of this composition mode. However, overprinting is deprecated by IOF.

Apart from contour lines and line frequency, changing to fulltone C for blue probably already mitigates issues with moiree on marches which are related to line width, pattern frequency and printer resolution. Other issues like the 402/709 interference indicate that pattern frequency should get more attention when designing symbol properties.

Andreasox commented 5 years ago

Thanks, this is roughly my understanding as well.

I do not know of any method Mapper/Qt/OCAD can use to overrule print driver settings, except complete rasterization.

I am responsible in Sweden for the color print certification (http://www.svenskorientering.se/Arrangera/kartfragor/Kartutskrifterochtryck/). March moiree do happen also for fulltone C with cheap printers like HP M553. It does not happen using expensive printers. I assume this "effect" has more to do with the type of rasterization (stochastic etc.) the printer device uses, i.e. can potentially only be mitigated by rasterization but probably not then either.

I will test Agnars values in the provided link but have tested many possible width/gap combination before without any 100% success.