Edgewall Software
Modify

Opened 5 years ago

Last modified 4 years ago

#8967 new defect

Partial conversion of files when calling trac.mimeview.api.Mimeview.convert_content

Reported by: olemis+trac@… Owned by:
Priority: normal Milestone: next-major-releases
Component: rendering Version: 0.11.5
Severity: major Keywords: mimeview, convertcontent
Cc:
Release Notes:
API Changes:

Description

In the aforementioned function there is a branch that is used to guess the content type of the input file. In order to do that max_preview_size bytes are read from the beginning of the file, and then the file is not used anymore. This means that only that first block is converted rather than the whole file.

The exact location of the code I am talking about is here

Attachments (0)

Change History (5)

comment:1 Changed 5 years ago by rblank

Well, yes, that's what max_preview_size is intended for. What were you expecting? Can you describe the situation where this is not desired?

comment:2 follow-up: Changed 5 years ago by cboos

  • Component changed from general to rendering
  • Milestone set to next-major-0.1X

Maybe in some situations, previewing a truncated document is not a good idea (at the very lest, the document will appear to be complete while it's actually truncated).

It would be preferable to not preview the content if its size is above the given limit. Related to #3332, as it would be nice to be able to get the size of the content without requiring to read it first.

comment:3 in reply to: ↑ 2 Changed 5 years ago by olemis+trac@…

Replying to cboos:

Maybe in some situations, previewing a truncated document is not a good idea (at the very lest, the document will appear to be complete while it's actually truncated).


That's part of the whole picture. BTW there are some other situations that could be considered e.g. the last bytes are needed to render the file. In my particular case, I am writing a plugin and I'd like to convert the whole file from original MIME type to target MIME type. If the file is truncated I cannot rely upon Trac MIME API to do that (therefore needing to reinvent the wheel due to a minor implementation detail).

It would be preferable to not preview the content if its size is above the given limit.


Therefore IMHO it would be better to perform such decisions outside the API itself (e.g. the plugin using the API for a particular purpose) or otherwise inside of it, but having the possibility to specify what is needed explicitly (I think I'd be +1 for the former ).


Related to #3332, as it would be nice to be able to get the size of the content without requiring to read it first.


Probably yes. That would be very useful to decide what to do before actually doing it ;o)

PS: Real-time preview is awesome. Keep up the good work !

:o)

comment:4 follow-up: Changed 4 years ago by Carsten Klein <carsten.klein@…>

perhaps splitting the mimetype api into a backend and frontend would do the job? with the backend being able to process arbitrary file sizes, and the frontend imposing a size limit to it?

afaik the original poster wants to implement some kind of conversion utility for mimetypes, in order to be able to transform arbitrary input types into arbitrary output types…

comment:5 in reply to: ↑ 4 Changed 4 years ago by olemis+trac@…

Replying to Carsten Klein <carsten.klein@…>:

perhaps splitting the mimetype api into a backend and frontend would do the job? with the backend being able to process arbitrary file sizes, and the frontend imposing a size limit to it?

afaik the original poster wants to implement some kind of conversion utility for mimetypes, in order to be able to transform arbitrary input types into arbitrary output types…

Exactly ! … but with efficiency in mind, so that if all contents are not needed then only some bytes are read

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The ticket will remain with no owner.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.