Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds a new loader for pdf preview #52

Closed
wants to merge 1 commit into from
Closed

Adds a new loader for pdf preview #52

wants to merge 1 commit into from

Conversation

lucasaba
Copy link
Contributor

@lucasaba lucasaba commented Mar 4, 2012

PdfPreviewLoader is an example of how, with a loader, it is
possible to preview virtually any file system type.
Extending FileSystemLoader, thanks to Lukas's code, PdfPreviewLoader
generate a png image of the first page of the pdf document and
updates the infos of the file to be rendered.

I think that it would be better to pass from config the number of the page to be extracted and the image format to use but... I'm not sure how this could be done...

PdfPreviewLoader is an example of how, with a loader, it
possible to preview virtually any file system type.
Extending FileSystemLoader, thanks to Lukas's code, PdfPreviewLoader
generate a png image of the first page of the pdf document and
updates the infos of the file to be rendered.
@lsmith77
Copy link
Contributor

lsmith77 commented Mar 4, 2012

Thanks .. one thing I realized when I got up this morning is that maybe this code should use composition. Aka instead of extending from FileSystemLoader, it should simply get a LoaderInterface injected. This way this logic could be combined with other loaders as well. I will think about it, but likely make a decision today.

if (isset($info['extension']) && strpos(strtolower($info['extension']), 'pdf') !== false ) {
//If it doesn't exists, extract first page of the PDF to png
if (!file_exists("$absolutePath.png")) {
$img = new \Imagick ( $absolutePath.'[0]' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are you instantiating Imagick here ? Couldn't you do this with Imagine so that it works for people using a different driver ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think this will work with other drivers .. but yeah maybe the instance could be fetched from imagine. @avalanche123

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can confirm that PDF file extension is supported only from Imagick and Gmagick. So the pdf pages can't be extracted with gd.
But I could try to get the used driver and throw an exception if the driver is GD.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense .. alternatively if the driver is GD, you could also just check if the extension is available and in that case make a new instance and only throw the exception if the extension is also not available

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I surrender: how can I retrieve the driver's name without injecting anything into PdfPreviewLoader ? (I'm missing those beautiful global variables and classes from S1.4).
Reading directly the configuration file is, obviously, not an option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm getting my head 'round the problem. I had to make some heavy changes but there's still a problem with stof's suggestion: imagine's implementation of Imagick doesn't support the "pdf opening syntax": $absolutePath.'[0]'.
It rises a 500 Server error: "File /home/luca/....../foobar.pdf[0] doesn't exist".
Imagine try to be as agnostic as possible and thus doesn't support Imagick constructor's parameters.

@lucasaba
Copy link
Contributor Author

lucasaba commented Mar 4, 2012

@stof I'm not sure that converting a pdf to an image can be done with GD and thus I didn't use Imagine. But I can dive a little bit more.

@lucasaba
Copy link
Contributor Author

lucasaba commented Mar 4, 2012

@lsmith77 That's just an idea but, I'm thinking that PdfPreviewLoader is not strictly a Loader but, let's call it, a transformer. Then, another solution could be to add one more level to the image processing: Loader->Transformer->Filter

@lsmith77
Copy link
Contributor

lsmith77 commented Mar 4, 2012

Yeah, thats an option, though I worry that we are making things too complicated, which is why I was pondering if the best approach isn't to just use object composition rather than inheritance:
http://en.wikipedia.org/wiki/Object_composition

This way we could look into making any loader useable with this PDF previewing.

@lucasaba
Copy link
Contributor Author

lucasaba commented Mar 5, 2012

I'm starting to find a profound lack of generality in this pull request. I think this code could find a better position inside an example folder.
In this way there would be no concern in forcing the use of imagick, in using object composition for resources loading (I'm thinking about an HttpLoader or something similar) and in making non-standard injection/configuration. What do you think about it ?

@lsmith77
Copy link
Contributor

lsmith77 commented Mar 5, 2012

it should definitely be possible to do this sort of thing in a clean reusable way. i will try to work on a solution over the course of this week. i guess for now you have at least a solution you can use.

@lucasaba
Copy link
Contributor Author

lucasaba commented Mar 6, 2012

Look at this: 47c825566aaf1aa4d4eff4f0db4c6cee6c6f960d
In this way there's an optional transformer statically called from the Loader.
It is easly reusable, clean and doesn't change the logic of the bundle.
I still have to add a TransformerInterface and some doc but I'll wait to know what you think about it.

@stof
Copy link
Contributor

stof commented Mar 6, 2012

why statically ?

@lucasaba
Copy link
Contributor Author

lucasaba commented Mar 6, 2012

I refuse to answer and plead the 5th amendment!
Well, to be honest, I don't need to initialize an object and I thought that using a static call would be cheaper than instantiating a new object. Am I wrong ? (a link to the necessary knowledge will be absolutely wellcome!)

@stof
Copy link
Contributor

stof commented Mar 6, 2012

static calls are generally harder to test, and makes it a pain if your transformer needs some dependencies. I think using an object is better as some transformers may need to use an object instead of a simple static method

@lucasaba
Copy link
Contributor Author

lucasaba commented Mar 6, 2012

You're absolutely right! And in this way, not only the transformer can be managed by the service container, but can also be an array of transformers! Here's the update: 9b19cf4617c588e96d6cecf9cd9ac573c4c9c354

@lucasaba
Copy link
Contributor Author

I had to cleanup my fork... I pushed a new PR: #57

@lucasaba lucasaba closed this Mar 12, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants