Smalltalk › Pharo › Pharo Smalltalk Users

JPEG support in Artifact

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Stephan Eggermont-3

JPEG support in Artifact

Reg Krock took a look at how difficult it would be to port Artefact to Gemstone.
He found that JPEG support uses a plugin based reader/writer, and seems to
render the JPEG using BitBlt and Form.

Why are JPEGs rendered? I’d think embedding them should be enough
(and be better for speed and image quality)

Stephan

Guillaume Larcheveque

Re: JPEG support in Artifact

If I remember well, we used this way to get some data about image required by PDF format.

Maybe there is a smarter way to do this, I will have a look with Olivier about this.

2014-04-03 10:32 GMT+02:00 Stephan Eggermont <[hidden email]>:

Reg Krock took a look at how difficult it would be to port Artefact to Gemstone.
He found that JPEG support uses a plugin based reader/writer, and seems to
render the JPEG using BitBlt and Form.

Why are JPEGs rendered? I’d think embedding them should be enough
(and be better for speed and image quality)

Stephan

--
Guillaume Larcheveque

Olivier Auverlot

Re: JPEG support in Artifact

Hi Stephan,

Yes, we have discussed with Guillaume. We don't have a better solution to propose but we will be really interested if someone write a portable JPEG support. It will be cool to have the possibility to extract header informations from pictures without using a plugin.

Best regards

2014-04-03 16:02 GMT+02:00 Guillaume Larcheveque <[hidden email]>:

If I remember well, we used this way to get some data about image required by PDF format.

Maybe there is a smarter way to do this, I will have a look with Olivier about this.

2014-04-03 10:32 GMT+02:00 Stephan Eggermont <[hidden email]>:

Reg Krock took a look at how difficult it would be to port Artefact to Gemstone.
He found that JPEG support uses a plugin based reader/writer, and seems to
render the JPEG using BitBlt and Form.

Why are JPEGs rendered? I’d think embedding them should be enough
(and be better for speed and image quality)

Stephan

--
Guillaume Larcheveque