no deskewing/orientation in GT about assets

[kba]

Needs to be specified ASAP in OCR-D/spec. Send PR for page-wise and line-wise rotation to PAGE-XML for upcoming 2019 version.

@chris1010010 @wrznr @bertsky @tboenig @cneud

[chris1010010]

Hi all, I might have mentioned in another thread, the full PAGE format collection has a dedicated XML format for this, as deskewing was seen as a pre-processing step that does not need to be reflected in the page content XML. But as it turned out, these other XML formats were never adopted much.
I guess adding the rotation doesn't hurt. Baselines would include the angles implicitly, but that's overkill in many cases I assume.
@wrznr @bertsky @tboenig @cneud

[bertsky]

Hi @chris1010010, thanks for your quick feedback!

Are you referring to the 2009 subschema deskew? This functionality would be superseeded completely if we had @orientation in PageType – we can already have the binary rotated image in AlternativeImage.

I would like to do the PR myself, but looking more closely, I have trouble interpreting the existing Region level attributes with certainty: @orientation sounds more like referring to the Coords.points, whereas @readingOrientation to the actual image. Is that impression correct? If so, are they mutually exclusive?

BTW, we just have a discussion on AlternativeImage based annotation including rotation issues here.

[chris1010010]

Hi @bertsky
Yes, I was referring to that subschema.
I always interpreted orientation and readingOrientation as additive.
Orientation is for the block/region in general. ReadingOrientation was intended for cases where the text is at an angle with reference to the block/region. We had examples somewhere, but only using orientation should be sufficient in most cases. In the current format I would probably use nested regions.

[bertsky]

Oh, I see. Thanks for the clarification!

I mentioned the additive semantics in the new PR.

[EEngl52]

@tboenig can this be closed?