Fix the Linux-only assumptions in the test suite and build on Windows - #481
Merged
Conversation
The logical AWT name "Helvetica" is not portable. On Windows it resolves
to Symbol, and DSS's TextFitter then fails measuring the first Latin glyph:
U+0053 ('S') is not available in the font Symbol.
Load the same DejaVuSans that DssFontUtils embeds for real signatures, so
the test measures text through the font production actually uses.
Path.toString() renders the platform separator, so the hardcoded "/tmp/x" expectations fail on Windows with "\tmp\x". Comparing Path to Path keeps the assertions platform-neutral.
SignerOptionsFromCmdLineTest exercises -q, which sets the app and global logger levels to OFF for the whole process. Surefire reuses one JVM and orders test classes by platform, so on Windows that test runs before the signing tests and every later log-capture assertion sees nothing: ExistingFieldSigningTest's three refusal/warning tests fail with an empty capture. Restore both levels after the test. Also assert the documented Windows outcome in tempFileIsRemovedAfterFailure: the abort leaves OpenPDF's RandomAccessFile open, so the delete cannot succeed there and the engine warns instead.
The sampler polled the staging directory every Thread.sleep(1L), which the platform timer granularity rounds up to ~15 ms on Windows. A sign that finishes in well under that fits between two looks and the staging file is never seen, so the test fails intermittently there. A WatchService reports the creation whenever it happens.
The suite carried four Linux-only assumptions that only a Windows runner caught (see #480). Build both platforms so the next one is caught in the PR. The test/windows-ci-** push trigger is temporary, to exercise the matrix before it reaches master.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #480.
The suite carried four Linux-only assumptions. Each fix uncovered the next, so all four are here.
JSignPdfSignatureDrawerTest: the logical AWT nameHelveticaresolves to Symbol on Windows and DSS'sTextFitterfails on the first Latin glyph. Loads the bundled DejaVuSans throughDSSFileFont, the same fontDssFontUtilsembeds for real signatures.NativeFileChooserTest:Path.toString()renders the platform separator, so the hardcoded/tmp/xexpectations fail with\tmp\x. ComparesPathtoPath.SignerOptionsFromCmdLineTest:-qsets the app and global logger levels toOFFfor the whole process, and the test never restored them. Surefire reuses one JVM and orders classes by platform: on Linux this test runs after the signing tests, on Windows before, silencing every later log-capture assertion (3 failures inExistingFieldSigningTest). Not a Windows bug — Linux passes on class ordering alone.BufferingModeSigningTest.stagingHonoursTheConfiguredDirectory: the staging directory was sampled onThread.sleep(1L), which the platform timer granularity rounds to ~15 ms on Windows, so a fast sign fits between two looks. Uses aWatchService.BufferingModeSigningTest.tempFileIsRemovedAfterFailureasserts the Windows outcome thatOpenPdfSigningEnginealready documents: the abort betweenpreClose()andclose()leaves OpenPDF's ownRandomAccessFileopen, so the delete cannot succeed and the engine warns instead. Production is unchanged; closing that handle needs its own issue.CI builds
windows-2025alongsideubuntu-24.04so the next one is caught in the PR.fail-fast: falsekeeps both results visible; surefire reports upload on failure only.Both legs green on the branch: https://github.com/intoolswetrust/jsignpdf/actions/runs/32064962283