text: add extended language property support

[bradh]

I went back-and-forward a bit on whether adding and getting should take the item or the item id. Would appreciate feedback on that.

[farindk]

I went back-and-forward a bit on whether adding and getting should take the item or the item id. Would appreciate feedback on that.

Yes, I can understand that. My first intuition would be to also use heif_text_item* for heif_item_get_property_extended_language(), similar to heif_error heif_text_item_add_extended_language(). That view might change if the elng box can also be assigned to other items (e.g. alternative images in different languages). I don't have the new standard yet, so I do not know whether elng is intended for that use too.

Another point: I would move all logic from the api/heif_*.cc file to the main library. Keep the logic in the core and only have C-type conversions in the api directory. I know that this is a bit of a mess currently, but if we try to separate it like this, it will be easier in the future to find the actual logic.

If you want, I can merge this and do the refactoring. Or you may do it if you prefer. Just let me know.

[bradh]

elng is only shown as a text item property in ISO 23008-12:2025. However the detail just comes from 14496-12, where it can be attached to a track.

Outside of specification conformance, I can think of a case where you might want to use it in a layered image, where the base layer is a photograph and there is a derived image using that base plus a selected labelling layer (with alpha) composited over the base layer. @dukesook have you looked at a photomap use case?

[farindk]

Outside of specification conformance, I can think of a case where you might want to use it in a layered image, where the base layer is a photograph and there is a derived image using that base plus a selected labelling layer (with alpha) composited over the base layer.

This may even be useful without a layered composition. I often have to handle software screenshots for different UI languages. These could then be combined into one file. For such a use, it might make sense to use an "alternative group" (altr) for language variants.

[bradh]

This may even be useful without a layered composition. I often have to handle software screenshots for different UI languages. These could then be combined into one file. For such a use, it might make sense to use an "alternative group" (altr) for language variants.

So I think we should allow for that. If you agree, I will update the interface to use a heif_item_id for both adding and getting. Potentially setting that property on a non-text item could be behind an experimental compile time flag, but as it would not be essential, then I do not see an issue with allowing it anywhere.

[farindk]

If you agree, I will update the interface to use a heif_item_id for both adding and getting.

Ok.

[dukesook]

elng is only shown as a text item property in ISO 23008-12:2025. However the detail just comes from 14496-12, where it can be attached to a track.

Outside of specification conformance, I can think of a case where you might want to use it in a layered image, where the base layer is a photograph and there is a derived image using that base plus a selected labelling layer (with alpha) composited over the base layer. @dukesook have you looked at a photomap use case?

Sorry, no. I'm not familiar with this.

[farindk]

I made a few small changes:

• the languages properties can now be accessed with either the plain item interface or through a heif_text_item.
• when setting a language to an item that already has a language property, it will throw an error. I think this is better than modifying the property because of the deduplication issue. Since we do not allow to modify existing files, there is currently no need to overwrite the item language.