allthingssecurity commented on code in PR #27344:
URL: https://github.com/apache/camel/pull/27344#discussion_r4181332514
##########
components/camel-barcode/src/main/java/org/apache/camel/dataformat/barcode/BarcodeDataFormat.java:
##########
@@ -236,12 +256,14 @@ public final void addToHintMap(final EncodeHintType
hintType, final Object value
*/
public final void addToHintMap(final DecodeHintType hintType, final Object
value) {
this.readerHintMap.put(hintType, value);
+ this.userReaderHintMap.put(hintType, value);
}
/**
* Removes a hint from writer (encode) hint map.
*/
public final void removeFromHintMap(final EncodeHintType hintType) {
+ this.userWriterHintMap.remove(hintType);
Review Comment:
Yes, done in be77632d4e00. `removeFromHintMap` now remembers the removal
(per encode/decode hint type) and
`optimizeHints()` removes those hints after computing the defaults, before
applying the user's added hints; adding the
hint again cancels the removal. So removing `ERROR_CORRECTION` or
`TRY_HARDER` before start works again as before
CAMEL-22354. Before start the "Could not find" WARN is replaced by an INFO
that the hint is removed when the data format
starts; after start a missing hint still logs the WARN. New test
`testHintsRemovedBeforeStart`: a default writer hint,
a default reader hint and an added-then-removed hint stay removed after
start, and the QR code is then written with
ZXing's error correction L (read back from the `ERROR_CORRECTION_LEVEL`
metadata) instead of the default H; adding
`ERROR_CORRECTION=M` again afterwards gives M. A control checks the default
H. The new test fails without the change;
module suite 35 tests, 0 failures.
_Claude Code on behalf of allthingssecurity_
##########
components/camel-barcode/src/main/java/org/apache/camel/dataformat/barcode/BarcodeDataFormat.java:
##########
@@ -188,13 +199,21 @@ private void printImage(final Exchange exchange, final
Object graph, final Outpu
// set values
final String type = this.params.getType().toString();
+ // ZXing writes the text in ISO-8859-1 unless a character set is
given, so use UTF-8 for a text that
+ // ISO-8859-1 cannot represent (ZXing then writes an ECI that tells
the reader the character set)
+ Map<EncodeHintType, Object> hints = writerHintMap;
+ if (!hints.containsKey(EncodeHintType.CHARACTER_SET) &&
!StandardCharsets.ISO_8859_1.newEncoder().canEncode(payload)) {
Review Comment:
Agreed, added in be77632d4e00 as `=== camel-barcode - text outside
ISO-8859-1` (there was no camel-barcode heading
yet; placed next to the other charset entries, before camel-bindy). It says
that non-Latin-1 text is now written in
UTF-8 with an ECI segment, that a reader without ECI support sees the UTF-8
bytes instead of `?`, that Latin-1 payloads
are byte-identical and a `CHARACTER_SET` hint takes precedence, and that the
documented default is now "ISO-8859-1, or
UTF-8 when needed".
_Claude Code on behalf of allthingssecurity_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
