-
Notifications
You must be signed in to change notification settings - Fork 902
Description
Bug description
The PDF signature dictionary is generated with two problems:
The /M (signature/modification date) always uses a plus sign (+) for the timezone, even when the local timeZoneOffset is negative.
The reserved space for the ByteRange is too small, which can make some PDF viewers fail when they try to replace the actual numbers, especially for large files.
Problem 1 – wrong timezone sign in /M:
Current behavior: the code builds the date string as
"D:{date}+HH'mm'"
so the sign is always “+”. This is incorrect for timezones such as UTC-3, and some viewers are strict about the PDF date format.
Expected behavior:
The date string must use the real sign from dateTime.timeZoneOffset and must format hours and minutes from the offset duration with two digits.
Suggested fix:
final Duration offset = dateTime.timeZoneOffset;
final String sign = offset.isNegative ? '-' : '+';
final String offsetHours = offset.inHours.abs().toString().padLeft(2, '0');
final String offsetMinutes = (offset.inMinutes.abs() % 60).toString().padLeft(2, '0');
dictionary!.setProperty(
PdfDictionaryProperties.m,
PdfString(
"D:${dateFormat.format(dateTime)}$sign$offsetHours'$offsetMinutes'",
),
);
This makes the PDF date look like:
D:YYYYMMDDHHmmSS-03'00' for UTC-3
D:YYYYMMDDHHmmSS+02'00' for UTC+2
Problem 2 – ByteRange placeholder too small:
Current behavior: only a small number of spaces is reserved before writing the ByteRange. When the actual values are longer than the reserved area, some PDF viewers break.
Suggested fix:
Increase the reserved area to something safely large, for example:
for (int i = 0; i < 200; i++) {
writer.write(PdfOperators.whiteSpace);
}
This ensures there is room for all four numbers of the ByteRange even in large PDFs.
Effect:
– The signature date is now compliant with the PDF date format and respects the real timezone.
– The ByteRange becomes robust for large files and for viewers that require enough reserved space.