Add support for font previews

[oparoz]

This will allow the preview system to generate both thumbnails and large previews of a type face

• Full screen previews requires a Gallery app which supports all media types supported by ownCloud

[oparoz]

cc @georgehrke @jancborchardt

[LukasReschke]

I'm not really sure if we should throw in even more not officially supported preview generators in core. - I'd prefer if apps coulf act as preview provider.

Generating previews is a potential very dangerous action as parsers are often not securely implemented or allow features which grant access to local resources.

Also the preview MQ is still something to discuss.

@DeepDiver1975 Let's discuss this whole topic at some point.

[oparoz]

I agree that the preview system needs to support plugins so that apps can augment its capabilities, but we're probably many months away from a solution which is going to migrate all the providers anyway, so my point of view is that those minor additions don't do any harm to the core since providers have to be enabled in the config anyway.

[DeepDiver1975]

I'm not really sure if we should throw in even more not officially supported preview generators in core. - I'd prefer if apps coulf act as preview provider.

Generating previews is a potential very dangerous action as parsers are often not securely implemented or allow features which grant access to local resources.

Also the preview MQ is still something to discuss.

Indeed - we need to introduce the job queue mechanism to allow decoupling and furthermore we need a public API to allow preview generators to be registered by apps.

[jancborchardt]

Since our main job is to show files, it would be good to have common file types supported for previewing. That’s of course where the discussion begins what is common and what is not. We could have an app handling advanced filetype previews, like these font files as well as RAW files (#13650)

[nickvergessen]

@DeepDiver1975

Indeed - we need to introduce the job queue mechanism to allow decoupling and furthermore we need a public API to allow preview generators to be registered by apps.

Should I try to do something similar like the activity manager?

[scrutinizer-notifier]

The inspection completed: 2 updated code elements

[ghost]

Refer to this link for build results (access rights to CI server needed):
https://ci.owncloud.org//job/pull-request-analyser-ng-simple/9925/
Test PASSed.

[MorrisJobke]

Indeed - we need to introduce the job queue mechanism to allow decoupling and furthermore we need a public API to allow preview generators to be registered by apps.

Should I try to do something similar like the activity manager?

@DeepDiver1975 @nickvergessen Is there any decision regarding this?

[nickvergessen]

I still vote for a preview app which contains all non-default previews and is done from the community.

[georgehrke]

I still vote for a preview app which contains all non-default previews

Why one app. It would be much easier to have multiple apps. Like preview_adobe or preview_gimp, etc. ...

[nickvergessen]

@georgehrke whatever number of app, all fine to me. Just don't put previews in core, which are then disabled, hard to set up and unmaintained ;)

[georgehrke]

@georgehrke whatever number of app, all fine to me. Just don't put previews in core, which are then disabled, hard to set up and unmaintained ;)

Totally agree with you here.

[oparoz]

@georgehrke - Except that it won't work, not unless we have a master Preview app which supports plugins. Those plugins can be dummy apps which only provide classes, but they should not offer controllers.
Apps are not going to send tons of HTTP requests to generate previews. They need to do one and then the backend calls the relevant classes.

[georgehrke]

Those apps should register preview providers, not more. We just need to make \OC\Preview\Provider public, so apps can extend from that.

[DeepDiver1975]

Should I try to do something similar like the activity manager?

that's the way to go from my pov - so: yes - THX

[oparoz]

@georgehrke - OK, it would indeed make things easier for admins, but then we still have to be able to use something like \OCP\IPreview to generate previews without making HTTP requests, because Preview is not only used via a URL to get a thumbnail...
This is discussed here: #13610

My main problem is that while this is not a big deal for fonts, as there is less demand, this is a bigger problems for Raw per example. A cloud is the perfect place to store these files, but you have to be able to see what DCR_201503082312.cr2 is.

So unless the new Preview app is fully functional in 8.1, I don't see a valid reason to block such new feature since all the current providers are going to be migrated anyway.

[georgehrke]

@georgehrke you want to take care of this?

The activity-manager like preview-provider-registering-service? Sure

[DeepDiver1975]

@georgehrke you want to take care of this?

I guess @georgehrke is rather busy with 🎓 and 📆 - 🙊

[georgehrke]

I should find time for this, shouldn't be a problem

[DeepDiver1975]

I should find time for this, shouldn't be a problem

well - you wanted to work on some other issues as well - https://github.com/owncloud/core/issues/assigned/georgehrke - I honestly question if you can add another issue to this ....

[georgehrke]

Okay, that's true

[MorrisJobke]

@nickvergessen Maybe you can have a look at this Preview class to be able to provide new preview provider within apps?

[DeepDiver1975]

So unless the new Preview app is fully functional in 8.1, I don't see a valid reason to block such new feature since all the current providers are going to be migrated anyway.

I tend to agree - this change is neither big nor critical and some public api will not be available over night.

👍

[MorrisJobke]

Looks good and works 👍

[MorrisJobke]

I created a ticket for the preview provider interface: #14803