Vlad Lipskiy

> This is consistent with JavaScript To be more precise it is consistent with IEEE 754, as non-number strings in comparisons with numbers now behave like NaN. For better or...

Either that, or make leading zeros not work in grammar and implementation. No strong opinions on either. Personally I lean towards the latter a tiny bit because of potential octal...

Well there could be other discrepancies, [not only with literals prefixes](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number#number_coercion): > Strings are converted by parsing them as if they contain a [number literal](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#numeric_literals). Parsing failure results in NaN....

Looks good. Maybe change "Number literals may include _a leading zero_" to "Number literals may include _leading zeros_"? To be more explicit. I'll test it a bit locally tomorrow.

Seems to be that everything is fine.

After some further testing, it looks like it is specifically the method being `protected abstract`. If it is `public abstract`, as with an interface, then it works fine.

Looks like this is, actually, a duplicate of #2192, though having `protected abstract` methods makes the issue more annoying... For now I've [forked it with a tweak to allow overriding...

Looks to be still relevant in `25.03` and it is coming from [the core library](https://github.com/itext/itext-java/blob/6d43eb7c01a9eb6d0df21e5d10b3a27b32660476/kernel/src/main/java/com/itextpdf/kernel/pdf/tagging/PdfStructTreeRoot.java#L96). Though, in theory, I could work around this in RUPS in read-only mode... If it...

Not in this case, as the created dictionary is direct. Unless you mean something else.

Is this on the `7.2.5` version or on the `develop` branch version? As of `7.2.5` you can only save PDF streams, and everything else throws an exception like this... It...