Skip to content

Future of hOCR #17

Description

@kba

hOCR is easy to implement because it's based on HTML but it can hardly be called a standard while there are living standards for OCR like ALTO.

hOCR is used by Open Source engines like tesseract, ocropy, kraken, cuneiform. Is their output spec-conformant and uniform? Would it not be better to enhance them to support ALTO if they do not already?

I like hOCR's approach for extensibility and microformat-like simplicity but it has not been updated for several years and I think it should not be used for new implementations unless there are very compelling reasons not to use ALTO.

That being said, there is software around that produces hOCR and related tools that expect hOCR (or some dialect of it).

What I think needs to be done in any case:

  1. Reduce the specs to the parts that are in actual use
  2. Restructure it to make it more coherent and provide more examples
  3. Produce a new major version indicating those changes and removals.

That new version should either be developed/refined further (e.g. by standardizing x* properties/classes) or contain a prominent deprecation notice that recommends another format like ALTO.

CC @tmbdev @mittagessen @zdenop @amitdo @zuphilip @cneud @stweil

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions