Tables as images

[fabiobatalha]

At Érudit a sort of documents could have their tables represented as images. It is important for us to have this supported in Texture.

[michael]

@fabiobatalha Would it be an option to use a <fig> element instead? It's a bit strange to mix contents, like we'd want the table to have just one tagging (and one type of content)and not so many alternatives (thinking of consistent UI/UX). Maybe we could do something about the labelling so that Table 1 is displayed instead of Figure 1.

[fabiobatalha]

@michael The idea is to support this:

object-id[pub-id-type=doi]?, label?, caption?, (table, graphic), table-wrap-foot?

The issue is that it is a Table and not a picture or figure and it is only being represented in the document as a binary file, but all the relation of this element with the rest of the document is as a Table.

I will double check if we can move on from tables as image and deal only with real tables.

[michael]

I understand. As you say it may be nice to move from image tables to real tables eventually. But we also consider this use-case if we agree it's needed for legacy purposes.

But please expect this to take some time as there's a lot of other requirements which I think should have priority.

[fabiobatalha]

@michael

We will probably move for real tables in a long term.

I'm not sure if it could be considered only as a legacy subject. Some tables of the paper could came from a external source that have/supply it only as an image.

Depending on the use license in the source, we may not be able to convert or reproduce this table as a structure xhtml table, and even though the author will still desire to represent it as a table in is work. I'm not sure if we have these use cases in our corpus but it seems to be a common use case.

@Melissa37 is this a use case in eLife? How you deal with tables from external sources that are available as images, but in the paper it should be represented as a Table?

[Melissa37]

@fabiobatalha at eLife they'd go through as figures but we'd keep an eye out for any tables sneaking through as figures and try and get the author to convert to a full text table or at least provide an Excel file as well. It's something we really discourage and so don't allow (only option is a figure) and we don't have true legacy content :-)

You raise a good point re licensing though - conditions for re-use could prevent full text?

[fabiobatalha]

@gustavofonseca do you have anything to contribute regarding to the SciELO deal with this?

[gustavofonseca]

Hi all

At SciELO we also discourage the representation of tables as figures, but in a lot of cases we end up accepting them based on the judgement of the QA team.

[lpanebr]

From the technical point of view, we only need figure tables when authors use those nasty diagonal cell splits which have no XML equivalent. When we do receive those though, we force the author to change the table.

[Melissa37]

@Melissa37 is this a use case in eLife? How you deal with tables from external sources that are available as images, but in the paper it should be represented as a Table?

I'd like @JGilbert-eLife to comment on this too, but we don't allow Tables that are figures, but I think we might have done in the past. When authors provide them as flat images we ask them to provide the original or re-key them- either they re-key or our production vendor does, but the author will check what's been done during proofing. Some authors sneak tables into figures and although we try to avoid this, sometimes we cannot. But that is not this use case as they would be tagged as figures (usually in a composite figure). We are in a different position to you guys though as we are in contact with the authors and it's part of our editorial and production requirements.

[JGilbert-eLife]

While I think we did skirt around doing this at a couple of points, I'm not sure if we've actually ever published an image as a table. I'm certainly struggling to find anything in our archive, though I can't completely rule it out.

Certainly we've always tried to discourage/avoid doing it.

[michael]

Tracked in requirements document. Closing.

[obuchtala]

I think we should keep these as open.

[fabiobatalha]

Continue at: https://github.com/substance/texture/issues/1322