Skip to content

Add Ghostscript 10.07.1 configuration and update bundle release#21

Merged
jwaisner merged 1 commit into
mainfrom
10.07.1
Jun 1, 2026
Merged

Add Ghostscript 10.07.1 configuration and update bundle release#21
jwaisner merged 1 commit into
mainfrom
10.07.1

Conversation

@N6REJ
Copy link
Copy Markdown
Contributor

@N6REJ N6REJ commented Jun 1, 2026

No description provided.

@N6REJ N6REJ added the enhancement ✨ Improve program label Jun 1, 2026
@qodo-code-review
Copy link
Copy Markdown

Review Summary by Qodo

Add Ghostscript 10.07.1 configuration and update release

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add Ghostscript 10.07.1 configuration files
• Create batch script for CID font map updates
• Update bundle release date to 2026.5.31
Diagram
flowchart LR
  A["Ghostscript 10.07.1"] --> B["bearsampp.conf"]
  A --> C["update_cidfmap.bat"]
  D["build.properties"] --> E["Release: 2026.5.31"]

Loading

Grey Divider

File Changes

1. bin/ghostscript10.07.1/bearsampp.conf ⚙️ Configuration changes +5/-0

Ghostscript 10.07.1 configuration file

• Defines Ghostscript 10.07.1 version configuration
• Specifies 64-bit GUI and console executable paths
• Sets bundle release version placeholder

bin/ghostscript10.07.1/bearsampp.conf


2. bin/ghostscript10.07.1/update_cidfmap.bat ✨ Enhancement +11/-0

CID font map update batch script

• Windows batch script for CID font map initialization
• Validates gswin64c.exe executable presence
• Executes mkcidfm.ps with Windows fonts directory
• Captures and propagates exit code

bin/ghostscript10.07.1/update_cidfmap.bat


3. build.properties ⚙️ Configuration changes +1/-1

Update bundle release date

• Updates bundle release date from 2026.4.12 to 2026.5.31

build.properties


Grey Divider

Qodo Logo

@qodo-code-review
Copy link
Copy Markdown

qodo-code-review Bot commented Jun 1, 2026

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0)

Grey Divider


Action required

1. Missing 10.07.1 release URL 🐞 Bug ≡ Correctness
Description
Adding bin/ghostscript10.07.1 makes Gradle discover version 10.07.1 via getAvailableVersions() and
attempt to build it, but downloadAndExtractGhostscript() throws when the version is not present in
releases.properties (and modules-untouched is absent). This makes builds for 10.07.1 (and
potentially releaseAll) fail with "Version 10.07.1 not found".
Code

bin/ghostscript10.07.1/bearsampp.conf[1]

Evidence
The build enumerates bin/ghostscript* directories as buildable versions, and when a version’s
binaries are missing locally it falls back to downloadAndExtractGhostscript(), which throws if the
version key isn’t found in releases.properties. releases.properties currently has entries up to
10.07.0 only, so 10.07.1 will fail in that fallback path.

bin/ghostscript10.07.1/bearsampp.conf[1-1]
build.gradle[895-906]
build.gradle[247-272]
releases.properties[1-11]
build.gradle[973-993]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The build discovers `10.07.1` from `bin/ghostscript10.07.1/`, but the Gradle build can only download binaries for versions present in `releases.properties` (when `modules-untouched` isn’t available). Since `releases.properties` has no `10.07.1` key, `gradle release -PbundleVersion=10.07.1` and `gradle releaseAll` will fail.

### Issue Context
- `getAvailableVersions()` enumerates `bin/ghostscript{version}` directories.
- `downloadAndExtractGhostscript()` requires a `releases.properties` entry for the version (or a local `modules-untouched` checkout).

### Fix Focus Areas
- releases.properties[1-11]
- build.gradle[247-272]
- build.gradle[895-906]

### Suggested fix
1. Add a `10.07.1 = <url-to-10.07.1-archive>` entry to `releases.properties`.
2. If the 10.07.1 archive URL is not known yet, either:
  - temporarily omit the `bin/ghostscript10.07.1/` directory until the URL is available, or
  - adjust the build to skip versions that lack both local binaries and a `releases.properties` entry (so `releaseAll` doesn’t hard-fail).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. pushd/popd mismatch 🐞 Bug ☼ Reliability
Description
update_cidfmap.bat does pushd but exits early when gswin64c.exe is missing, skipping popd and
leaving the caller in a different directory. This can break subsequent relative-path operations in
the invoking shell or batch script.
Code

bin/ghostscript10.07.1/update_cidfmap.bat[R3-7]

Evidence
The script executes pushd and then performs an early exit /b 1 in the missing-exe branch before
reaching popd, so cleanup is skipped.

bin/ghostscript10.07.1/update_cidfmap.bat[3-11]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`update_cidfmap.bat` performs `pushd "%~dp0"` and then `exit /b 1` inside the error branch without executing `popd`, so the directory stack/current directory is not restored.

### Issue Context
This script is likely to be run from other batch files; leaking the working directory can cause later relative-path commands to run in the wrong directory.

### Fix Focus Areas
- bin/ghostscript10.07.1/update_cidfmap.bat[3-11]

### Suggested fix
Refactor to guarantee cleanup, e.g.:
- Use a common `:cleanup` label and `goto cleanup` on error.
- Or inline: `popd & exit /b 1` inside the `if not exist (...)` block.
Also consider keeping `popd` in a `finally`-like pattern for all exit paths.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. 64-bit exe hardcoded 🐞 Bug ≡ Correctness
Description
bearsampp.conf and update_cidfmap.bat hardcode gswin64*.exe, but the build explicitly supports
either gswin64c.exe or gswin32c.exe and creates bin/gs.exe from whichever exists. On
32-bit-only inputs, the shipped config/script will reference non-existent binaries and fail at
runtime.
Code

bin/ghostscript10.07.1/bearsampp.conf[R2-3]

Evidence
The build and documentation explicitly support the presence of either 64-bit or 32-bit Ghostscript
console executables and the build creates gs.exe as a stable alias, but the new config/script
require 64-bit filenames only.

bin/ghostscript10.07.1/bearsampp.conf[1-3]
bin/ghostscript10.07.1/update_cidfmap.bat[4-9]
build.gradle[648-655]
build.gradle[678-687]
.gradle-docs/CONFIGURATION.md[154-160]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The config/script refer to `gswin64.exe`/`gswin64c.exe`, but the build supports 32-bit sources too and always creates a stable `bin/gs.exe` alias. Hardcoding 64-bit filenames breaks execution when only 32-bit executables are present.

### Issue Context
- Build logic: picks `gswin64c.exe` OR `gswin32c.exe`, then copies it to `bin/gs.exe`.
- Docs also indicate at least one of 64-bit/32-bit console executables may be present.

### Fix Focus Areas
- bin/ghostscript10.07.1/bearsampp.conf[1-5]
- bin/ghostscript10.07.1/update_cidfmap.bat[4-9]
- build.gradle[648-655]
- build.gradle[678-687]
- .gradle-docs/CONFIGURATION.md[154-160]

### Suggested fix
1. Update `update_cidfmap.bat` to invoke `bin\\gs.exe` (and check for it) instead of `gswin64c.exe`.
2. Update `bearsampp.conf` to point `ghostscriptExeConsole` at `bin/gs.exe`.
3. If `ghostscriptExe` must support both architectures too, either:
  - create an additional GUI alias during packaging (e.g., copy `gswin64.exe`/`gswin32.exe` to a common name), then reference that in the config, or
  - adjust runtime to prefer `gs.exe` for non-GUI use cases.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

@@ -0,0 +1,5 @@
ghostscriptVersion = "10.07.1"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Missing 10.07.1 release url 🐞 Bug ≡ Correctness

Adding bin/ghostscript10.07.1 makes Gradle discover version 10.07.1 via getAvailableVersions() and
attempt to build it, but downloadAndExtractGhostscript() throws when the version is not present in
releases.properties (and modules-untouched is absent). This makes builds for 10.07.1 (and
potentially releaseAll) fail with "Version 10.07.1 not found".
Agent Prompt
### Issue description
The build discovers `10.07.1` from `bin/ghostscript10.07.1/`, but the Gradle build can only download binaries for versions present in `releases.properties` (when `modules-untouched` isn’t available). Since `releases.properties` has no `10.07.1` key, `gradle release -PbundleVersion=10.07.1` and `gradle releaseAll` will fail.

### Issue Context
- `getAvailableVersions()` enumerates `bin/ghostscript{version}` directories.
- `downloadAndExtractGhostscript()` requires a `releases.properties` entry for the version (or a local `modules-untouched` checkout).

### Fix Focus Areas
- releases.properties[1-11]
- build.gradle[247-272]
- build.gradle[895-906]

### Suggested fix
1. Add a `10.07.1 = <url-to-10.07.1-archive>` entry to `releases.properties`.
2. If the 10.07.1 archive URL is not known yet, either:
   - temporarily omit the `bin/ghostscript10.07.1/` directory until the URL is available, or
   - adjust the build to skip versions that lack both local binaries and a `releases.properties` entry (so `releaseAll` doesn’t hard-fail).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@jwaisner jwaisner merged commit f81f049 into main Jun 1, 2026
3 checks passed
@jwaisner jwaisner deleted the 10.07.1 branch June 1, 2026 23:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement ✨ Improve program

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants