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]

How about replacing the existing elng?
Currently, we do not allow editing existing files, but if we will, replacing the value would be the expected behavior.

[bradh]

I originally tried removing the existing elng and adding a new one. That turned out to be very messy because it requires updating the property associations.

So I made the choice to update the text. However it might be unexpected that updating the text could affect another item with the same original text (because de-duplication).