Harlequin Core 14.0r4 Release Notes
Harlequin Core v14.0r4 is the next quarterly maintenance release since v14.0r3 in June 2025. This release builds on v14.0r0 from 2024 in that it addresses issues found by OEMs and includes further stability, performance and output quality improvements.
In addition to some planned development of the product, where we respond to customer issues, the Jira portal HQNSUP reference number is included in the "Harlequin Core v14.0r4 change details" table (below).
No Harlequin MultiRip (HMR) distributions have been built and tested for 14.0r4. If you require an HMR distribution please contact your account manager.
Highlights
Output changes
OEMs should be aware that in some configurations, differences in the pixels produced by the RIP will be visible. These are unavoidable in order to maintain our compatibility with other PDF rendering products. In this release there are two changes that may affect your output rasters:
HQN-386025 - Defect in positioning and scaling TrueType glyphs with certain component-flags set
A defect was identified in the handling of TrueType glyphs that use rare component-flags related to space scaling. In affected jobs such glyphs were not rendered correctly, resulting in blank space where characters are expected or clipped output when processed with certain configurations. The issue was traced to incorrect logic in the positioning and scaling of composite glyphs, particularly in the application of transformation matrices and range clipping.
This release updates the TrueType vector pipeline to correctly handle these component-flags, ensuring accurate rendering of composite glyphs, including those involving rotations and complex scaling. Extensive regression testing was performed and minor pixel-level differences may be observed at low resolutions e.g 600ppi and below. Output at production resolutions is now correct where it previously wasn't.
This is an example of the issue: an incorrectly rendered glyph on the left and corrected on the right. The RIP’s output now matches Acrobat and Hybrid Packz.
HQN-386479 - unwanted artifacts in the RIP output when Beziers have co-incident control points
A customer reported unwanted artifacts in the RIP output on “pointy” letters. We confirmed the issue in Harlequin v14.0r3 and identified it as related to mitre limits in vector objects that caused incorrect mitre angles in the output. The issue was resolved by modifying the Bezier algorithm to handle these special cases correctly, ensuring accurate rendering of curves. The fix has been thoroughly tested, with minor pixel differences observed in some test jobs but no unexpected regressions. The update improves the fidelity of Bezier curve rendering and aligns the output more closely with Acrobat.
Harlequin Core v14.0r3 and earlier 
Acrobat, Harlequin Core v14.0r4 and later 
Harlequin Core v14.0r4 change details
Jira Story | Support call(s) | Summary |
|---|---|---|
HQN-386473 | n/a | Possible bad output using HVD with certain aliased colorants |
HQN-386483 | HQNSUP-127191 | IndependentSpots doesn't work correctly if not the first spots in SeparationColorNames bug triggered when the OutputColorants list places White at the end instead of earlier, affecting the independent spots feature |
HQN-386455 | HQNSUP-127168 | Fix Memory Leak and Slowdown With OverprintPreview and HqnImpose2 |
HQN-386417 | SDFESUP-1372 | Large lengthy Chinese VDP file fails when -nrips specified |
HQN-386279 | HQNSUP-127128 | Add a parameter to control faux styling of simple PDF fonts |
HQN-386271 | n/a | Speed HVD up without using hit counts from previous chunks for jobs where reuse is irregular |
HQN-386197 | n/a | Turn off separation detection as default |
HQN-385907 | HQNSUP-126959 | Fix: Stroke curve offsetting may introduce visual artifacts. |
HQN-386454 | n/a | HVD: Remove /OptimizedPDFGroupOverprinting param |
HQN-386025 | HQNSUP-127010/HHR#2630 | Bug in positioning and scaling TrueType glyph with certain component-flags set. / A font does not render correctly. See Release Note Highlights |
HQN-386479 | HQNSUP-127173 | unwanted artifacts in the RIP output when Beziers have co-incident control points |
HQN-386018 | HQNSUP-126996 | HqnContour config without LayerComments /Export causes clrip to crash |
HQN-386505 | HQNSUP-127182 | 14.0r2 compared to 14.0r3 showing performance differences for some jobs in complex color configurations |
Known issues
HQN-386003 - Correct MPS not to exceed the process' maximum number of mappings on Linux
it was found that the default max_map_count on Ubuntu and Red Hat was not sufficient to allow some jobs to complete normally even with a huge memory of 120Gb. The workaround is to set max_mem_count to 1048576, which prevents this stuck loop at the end of the job. Scheduled in v14.1.
HQN-385923 - Scalable crashes on startup on PCs with CPUs without AVX2 support
Running a scalable RIP on an Ubuntu VM without AVX2 SIMD support can result in a crash from ZeroMQ initialising static data. Checking the CPU flags for the VM revealed it did not have AVX2 enabled.
HQN-385755 - linker warning Harlequin Core (HHR) SDK
When building the Win64 release in MSVS 2022, you may get several benign linker warnings, e.g. “hhrsdklib.lib(deverrors.obj) : warning LNK4099: PDB'' was not found with 'hhrsdklib.lib(deverrors.obj)' or at ''; linking object as if no debug info. These can be suppressed in the project.
Documentation changes
Document | Status |
|---|---|
updated |
Changes to Windows Code Signing Process
Following the announcement in release v14.0r3 about reversion to internal signing for Windows builds, we are pleased to confirm that Harlequin releases are now Windows-signed again meaning:
All Windows release executable files are now code signed to show they come from a verified source and have not been tampered with
OEMs can continue to redistribute signed builds without requiring additional signing steps
Windows code-signed executables prevent security prompts and delays when running the release
Note: rebuilding any part or the HHR SDK on Windows using the supplied project files will remove the existing code signing, and OEMs will need to code-sign them.