Robert Sachunsky

> No, I mean correcting a photo not taken orthogonally to the plane (paper) (=perspective distortion). The vertical column separators are not parallel in the scan. Since we had scans...

Yes, again, a case for OCR-D/core#252

I think what @tboenig meant was suspiciously small _text_ regions (and lines). And yes, that would have to depend on the DPI of the input, too. And yes, it could...

@cneud Absolutely! This is not about the XML syntax, but about our (application-specific) semantic constraints. So maybe we should call this whole thing __evaluation__ instead of validation, and have the...

I can confirm it is necessary to escape the right curly brace in the second argument to the `tokenize` function with SaxonHE10-6J. (Not sure about the other escapes here, though.)

Note: Above link was merely the example, the [actual proposal](https://github.com/altoxml/schema/issues/57#issuecomment-510042975) was a few comments before that. In my view, the most significant progress over that was the aspect of **backwards...

Thanks @artunit! To complement the discussion on a possible lattice extension to fully represent OCR ambiguity with a perspective more inclined to an extension based on the **confidence/confusion matrix** (henceforth,...

The change proposed by @Jo-CCS and adopted into 4.0-4.2 includes this detail of restricting "character" length that seems overly restrictive to me, not just with respect to OCR results, but...

Please forgive my intrusion, but I think I can help with some outsider's perspective. Let me go back a little: > There seems to be reluctance to add intricate XML...

That's precisely my use case, too! (I am doing [post-correction](ASVLeipzig).) The OCR and LM scores can be added/multiplied with each other (with a given weight) and annotated under `WC` or...