Skip to content
This repository has been archived by the owner on Jan 2, 2023. It is now read-only.

C API - TempFiles seem to be deleted early #1790

Closed
tuespetre opened this issue Jun 20, 2014 · 9 comments
Closed

C API - TempFiles seem to be deleted early #1790

tuespetre opened this issue Jun 20, 2014 · 9 comments
Labels
Milestone

Comments

@tuespetre
Copy link

Reference:

tuespetre/TuesPechkin#23

When using the C API, creating a converter and adding multiple objects with HTML byte data results in only the last object being printed with the others showing up blank. The temp files that wkhtmltopdf creates to store the HTML byte data seem to be deleted early, resulting in an error similar to the following for each of the previous objects:

Conversion Warning: Failed loading page file:///C:/Users/grayd/AppData/Local/Temp/wktemp-f19b085a-e516-4151-8786-9dc351d4baa7.html (ignored)

@tuespetre
Copy link
Author

I've done my best to track this down:

When conversion is starting, each object is looped through and added as a resource to the loader:

for (QList<PageObject>::iterator i=objects.begin(); i != objects.end(); ++i) {

...and as each resource is added to the loader, a temp file is created:

LoaderObject * MultiPageLoader::addResource(const QString & string, const settings::LoadPage & s, const QString * data) {

...but when the next temp file is created, the previous one is removed:

...so then when the loader loads, the temp files will be missing:

#ifdef __EXTENSIVE_WKHTMLTOPDF_QT_HACK__

It looks like the loader needs to have a collection of TempFile objects rather than one that keeps shooting itself in the foot ;)

@ashkulz
Copy link
Member

ashkulz commented Jun 22, 2014

@tuespetre: definitely looks like a bug, but I don't know if I will be able to look into it for a day or two.

@ashkulz ashkulz added this to the 0.12.1 milestone Jun 22, 2014
@tuespetre
Copy link
Author

That's fine, I know how that goes. Is there still time to include this in 0.12.1? I see the milestone on the issue now, nevermind!

@ashkulz ashkulz modified the milestones: 0.12.2, 0.12.1 Jun 27, 2014
@ashkulz
Copy link
Member

ashkulz commented Jun 27, 2014

Milestone changed to 0.12.2 as it doesn't look too easy to address 😦

@poizan42
Copy link
Contributor

poizan42 commented Aug 1, 2014

Why is it even using temp files? Sounds like a job for a custom protocol handler - or is that too much work to create?

@ashkulz ashkulz closed this as completed in 915ba31 Jan 3, 2015
ashkulz added a commit that referenced this issue Jan 3, 2015
The TempFile class was able to handle only one file, but was used
in scenarios where multiple temp files were required. Change the
implementation and API to support this usage scenario, which also
fixes #1790.

Ideally, one should do away with this and use an in-memory QtWebKit
protocol [1] e.g. mem://uuid.html but that is something to be taken
up after refactoring of the current codebase.

[1] http://doc.qt.digia.com/qq/32/qq32-webkit-protocols.html
@ashkulz ashkulz added Fixed and removed Verified The issue is verified. labels Jan 3, 2015
@ashkulz
Copy link
Member

ashkulz commented Jan 3, 2015

Please test the changes and let me know if you encounter an issue, as I'm planning to make the 0.12.2 release in the next week.

@ashkulz
Copy link
Member

ashkulz commented Jan 4, 2015

A release candidate 0.12.2-rc-71e97c1 is available, which should fix this issue. Please report back if your issue is not solved with the above build.

@tuespetre
Copy link
Author

This one is all kosher and baller and etc., thank you!

@ashkulz
Copy link
Member

ashkulz commented Jan 10, 2015

0.12.2 has been released, which includes changes related to this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

3 participants