Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
JPeg-into-Impression utility
35 views
Skip to first unread message
Jim Nagel
Apr 10, 2013, 10:06:39 AM4/10/13
to
I'd be first in the queue to buy a little standalone utility that
would accept a JPeg, wrap a little bit of Artworks code around head
and tail of it and drop it into an Impression frame. (The user does
not require the full Artworks application, only the free !AWviewer
that lives in Resources.)
Alas, I'm not enough of an expert to work out what certain bytes in
the tail mean (sounds like a cyberscorpion!) -- probably size,
resolution and position of the JPeg within the concocted Artwork, in
bigendian notation or something.
Martin W�rthner tells me it's a simple enough project, and that the
Impression loader routines might even handle it transparently, but
that he doesn't have time to do it himself. He said he would not be
able to reveal the Artworks file format, but that the necessaries
would be easy enough for someone to reverse-engineer. He would be
willing to vet the utility before its release in order to verify that
it produces valid Artworks code.
Any coder out there interested in having a go? If so, contact me and
I'll give you results of experiments I've done so far. And some specs
that I'd bear in mind from the outset.
I'm sure every other Impression user would find this utility worth
spending a bit of dosh on. I do the process manually for every
picture that appears in the magazine.
--
Jim Nagel www.archivemag.co.uk
See you at Wakefield? www.wakefieldshow.org.uk April 20
would accept a JPeg, wrap a little bit of Artworks code around head
and tail of it and drop it into an Impression frame. (The user does
not require the full Artworks application, only the free !AWviewer
that lives in Resources.)
Alas, I'm not enough of an expert to work out what certain bytes in
the tail mean (sounds like a cyberscorpion!) -- probably size,
resolution and position of the JPeg within the concocted Artwork, in
bigendian notation or something.
Martin W�rthner tells me it's a simple enough project, and that the
Impression loader routines might even handle it transparently, but
that he doesn't have time to do it himself. He said he would not be
able to reveal the Artworks file format, but that the necessaries
would be easy enough for someone to reverse-engineer. He would be
willing to vet the utility before its release in order to verify that
it produces valid Artworks code.
Any coder out there interested in having a go? If so, contact me and
I'll give you results of experiments I've done so far. And some specs
that I'd bear in mind from the outset.
I'm sure every other Impression user would find this utility worth
spending a bit of dosh on. I do the process manually for every
picture that appears in the magazine.
--
Jim Nagel www.archivemag.co.uk
See you at Wakefield? www.wakefieldshow.org.uk April 20
Matthew Phillips
Apr 11, 2013, 3:14:09 AM4/11/13
to
In message <90eb393...@nails.abbeypress.net>
check this myself.
I understand that Impression does not support adding JPEGs direct to
documents, so the ArtWorks thing is a work-around. Why do you need to wrap
the JPEG in an ArtWorks file particularly? Could you not put the JPEG inside
a Draw file instead? Surely Draw files can be put into Impression documents?
If Draw would do, the format is fully documented and it would be a much
quicker job for a developer. In fact, we already have most of the necessary
code lying around here as this is exactly the method DrawPrint uses to
support printing JPEGs.
One question is whether ArtWorks has support for a wider range of JPEGs than
the DrawFileRender module. That may be a reason to use ArtWorks over Draw.
--
Matthew Phillips
Durham
on 10 Apr 2013 Jim Nagel wrote:
> I'd be first in the queue to buy a little standalone utility that
> would accept a JPeg, wrap a little bit of Artworks code around head
> and tail of it and drop it into an Impression frame. (The user does
> not require the full Artworks application, only the free !AWviewer
> that lives in Resources.)
This is probably a stupid question, but as I do not have Impression I cannot
> I'd be first in the queue to buy a little standalone utility that
> would accept a JPeg, wrap a little bit of Artworks code around head
> and tail of it and drop it into an Impression frame. (The user does
> not require the full Artworks application, only the free !AWviewer
> that lives in Resources.)
check this myself.
I understand that Impression does not support adding JPEGs direct to
documents, so the ArtWorks thing is a work-around. Why do you need to wrap
the JPEG in an ArtWorks file particularly? Could you not put the JPEG inside
a Draw file instead? Surely Draw files can be put into Impression documents?
If Draw would do, the format is fully documented and it would be a much
quicker job for a developer. In fact, we already have most of the necessary
code lying around here as this is exactly the method DrawPrint uses to
support printing JPEGs.
One question is whether ArtWorks has support for a wider range of JPEGs than
the DrawFileRender module. That may be a reason to use ArtWorks over Draw.
--
Matthew Phillips
Durham
David Holden
Apr 11, 2013, 3:43:13 AM4/11/13
to
On 11-Apr-2013, Matthew Phillips <spam...@yahoo.co.uk> wrote:
> I understand that Impression does not support adding JPEGs direct to
> documents, so the ArtWorks thing is a work-around. Why do you need
> to wrap the JPEG in an ArtWorks file particularly? Could you not
> put
> the JPEG inside a Draw file instead? Surely Draw files can be put
> into
> Impression documents?
it's an image in Draw format but (I assume) tries to display it itself
and can't cope.
--
David Holden - APDL - www.apdl.co.uk
C J Craig
Apr 11, 2013, 4:05:10 AM4/11/13
to
My version of Impression Publisher (4.11) will accept small JPEGS
100,000 bytes but 1 Meg, You get egg timer then screen goes black and
computer can not be re-started from the keyboard. Trys a low res
screen mode but just black??.. Perhaps it because I have Artworks 2
modules installed allowing the JPEGS to transfer to Impression??
Chris
In message <90eb393...@nails.abbeypress.net>
C J Craig
Ch...@skipton.demon.co.uk
Iyonix ARM XScale computer RISC OS 5.18
100,000 bytes but 1 Meg, You get egg timer then screen goes black and
computer can not be re-started from the keyboard. Trys a low res
screen mode but just black??.. Perhaps it because I have Artworks 2
modules installed allowing the JPEGS to transfer to Impression??
Chris
In message <90eb393...@nails.abbeypress.net>
Ch...@skipton.demon.co.uk
Iyonix ARM XScale computer RISC OS 5.18
Jim Nagel
Apr 11, 2013, 8:38:30 AM4/11/13
to
C J Craig wrote on 11 Apr:
Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
Impression frame brings up this familiar old error message:
That file type is not currently understood.
Click OK to load it as an embedded object,
Cancel to ignore it.
OK produces a full-frame *file icon* for JPeg. So that's no use.
No eggtimer or black screen or freeze, though.
I too have Artworks2 running, and !AWrender in Boot.Resources, but
neither are involved in the above action.
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
> My version of Impression Publisher (4.11) will accept small JPEGS
> 100,000 bytes but 1 Meg, You get egg timer then screen goes black and
> computer can not be re-started from the keyboard. Trys a low res
> screen mode but just black??.. Perhaps it because I have Artworks 2
> modules installed allowing the JPEGs to transfer to Impression??
> 100,000 bytes but 1 Meg, You get egg timer then screen goes black and
> computer can not be re-started from the keyboard. Trys a low res
> screen mode but just black??.. Perhaps it because I have Artworks 2
Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
Impression frame brings up this familiar old error message:
That file type is not currently understood.
Click OK to load it as an embedded object,
Cancel to ignore it.
OK produces a full-frame *file icon* for JPeg. So that's no use.
No eggtimer or black screen or freeze, though.
I too have Artworks2 running, and !AWrender in Boot.Resources, but
neither are involved in the above action.
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
C J Craig
Apr 11, 2013, 12:15:20 PM4/11/13
to
In message <9eafb53...@nails.abbeypress.net>
>
> I too have Artworks2 running, and !AWrender in Boot.Resources, but
> neither are involved in the above action.
I do not have !AWrender in !Boot but I do have !AWViewer in
!Boot.Resources.. There is DRenderer in !System.310.Modules.
My version of Impression has AWRender (module 1.22) in
Impression.!Publisher.RMStore
Chris
Jim Nagel <jimne...@abbeypress.co.uk> wrote:
> C J Craig wrote on 11 Apr:
>> My version of Impression Publisher (4.11) will accept small JPEGS
[snip]
> C J Craig wrote on 11 Apr:
>> My version of Impression Publisher (4.11) will accept small JPEGS
> Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
> Impression frame brings up this familiar old error message:
[snip]
> Impression frame brings up this familiar old error message:
>
> I too have Artworks2 running, and !AWrender in Boot.Resources, but
> neither are involved in the above action.
!Boot.Resources.. There is DRenderer in !System.310.Modules.
My version of Impression has AWRender (module 1.22) in
Impression.!Publisher.RMStore
Chris
Jim Nagel
Apr 11, 2013, 1:22:22 PM4/11/13
to
C J Craig wrote on 11 Apr:
> I do not have !AWrender in !Boot but I do have !AWViewer in
> !Boot.Resources.
Oops, my mistake; sorry to confuse. I did mean !AWviewer in
> !Boot.Resources.
!Boot.Resources. The module AWrender is a component within it.
Mine is version 2.16 (dated 2011-11-12), which is the latest one at
its source, http://mw-software.com/software/awmodules/awrender.html
(free).
See the internal file !ReadmeMW for notes about removing other copies
of the module AWrender from your system and special attention required
by Impression running under Aemulor on the Iyonix.
--
Jim Nagel www.archivemag.co.uk
Jim Nagel
Apr 11, 2013, 1:29:50 PM4/11/13
to
Matthew Phillips wrote on 11 Apr:
particularly, if the openly-documented Draw could be made to do the
job. Artworks will do it already, thanks to the free !AWrender (which
lives in !Boot.Resources) -- I was wishing for a utility to automate
my repetitive manual steps.
But Draw apparently will need some equivalent module to be extended.
I already knew Draw could accept a JPeg, but when that drawfile is
dropped into Impression only a blank appears.
I did further experiments with other graphic formats and am surprised
to find that Draw also accepts PNG -- very welcome: Martin W hasn't
yet given in to requests and added PNG support to Artworks. Moreover,
this drawfile CAN be dropped into an Impression frame, the PNG
appears, *and* Impression's "Alter graphic" dialogue actually shows
the *resolution* of the PNG.
This rates as Discovery of the Month! From now on I shall use PNGs
in the magazine instead of JPegs in situations where JPegs acquire
unpleasant blobs -- particularly certain screenshots. (JPegs are
still essential, though: it would be counterproductive to introduce
the extra step of changing JPegs to PNGs, which are often larger.)
I'm talking about Draw 2.27 (dated 2004, came with Ro 4.39). The Rool
version of Draw ("1.20", dated 2012) is more primitive, doesn't handle
PNG.
Curiously, ROL's Draw 2.27 does seem to run on the Iyonix (Ro 5.18)
but dropping a PNG into it produces error "Draw cannot load this"; I
guess some other support module is involved.
Of course Impression since the year dot has always imported a sprite
by wrapping it in a drawfile, and its dialogue shows the resolution of
the sprite taking into account its magnification in the Impression
frame -- which is essential information before printing.
If you want to see a table of my experiments, and the sample files I
used: www.archivemag.co.uk/JN/impressiontest.zip (38K)
> One question is whether ArtWorks has support for a wider range of JPEGs than
> the DrawFileRender module. That may be a reason to use ArtWorks over Draw.
We'd have to ask Martin Wuerthner that. But Artworks has so far
handled all the JPegs I've thrown at it. (version 2.XI.01, dated 2011)
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
> Why do you need to wrap the JPEG in an ArtWorks file particularly?
> Could you not put the JPEG inside a Draw file instead? Surely Draw
> files can be put into Impression documents?
> If Draw would do, the format is fully documented and it would be a much
> quicker job for a developer. In fact, we already have most of the necessary
> code lying around here as this is exactly the method DrawPrint uses to
> support printing JPEGs.
That sounds promising! You're right: it doesn't need to be Artworks
> Could you not put the JPEG inside a Draw file instead? Surely Draw
> files can be put into Impression documents?
> If Draw would do, the format is fully documented and it would be a much
> quicker job for a developer. In fact, we already have most of the necessary
> code lying around here as this is exactly the method DrawPrint uses to
> support printing JPEGs.
particularly, if the openly-documented Draw could be made to do the
job. Artworks will do it already, thanks to the free !AWrender (which
lives in !Boot.Resources) -- I was wishing for a utility to automate
my repetitive manual steps.
But Draw apparently will need some equivalent module to be extended.
I already knew Draw could accept a JPeg, but when that drawfile is
dropped into Impression only a blank appears.
I did further experiments with other graphic formats and am surprised
to find that Draw also accepts PNG -- very welcome: Martin W hasn't
yet given in to requests and added PNG support to Artworks. Moreover,
this drawfile CAN be dropped into an Impression frame, the PNG
appears, *and* Impression's "Alter graphic" dialogue actually shows
the *resolution* of the PNG.
This rates as Discovery of the Month! From now on I shall use PNGs
in the magazine instead of JPegs in situations where JPegs acquire
unpleasant blobs -- particularly certain screenshots. (JPegs are
still essential, though: it would be counterproductive to introduce
the extra step of changing JPegs to PNGs, which are often larger.)
I'm talking about Draw 2.27 (dated 2004, came with Ro 4.39). The Rool
version of Draw ("1.20", dated 2012) is more primitive, doesn't handle
PNG.
Curiously, ROL's Draw 2.27 does seem to run on the Iyonix (Ro 5.18)
but dropping a PNG into it produces error "Draw cannot load this"; I
guess some other support module is involved.
Of course Impression since the year dot has always imported a sprite
by wrapping it in a drawfile, and its dialogue shows the resolution of
the sprite taking into account its magnification in the Impression
frame -- which is essential information before printing.
If you want to see a table of my experiments, and the sample files I
used: www.archivemag.co.uk/JN/impressiontest.zip (38K)
> One question is whether ArtWorks has support for a wider range of JPEGs than
> the DrawFileRender module. That may be a reason to use ArtWorks over Draw.
handled all the JPegs I've thrown at it. (version 2.XI.01, dated 2011)
--
Jim Nagel www.archivemag.co.uk
>> "from" address is genuine but will change. website has current one.
Matthew Phillips
Apr 11, 2013, 4:26:49 PM4/11/13
to
In message <db5bd03...@nails.abbeypress.net>
Draw file itself using the Draw module calls. Impression of course predates
DrawFile_Render and handling JPEG objects in Draw files must never have been
added (if they had done that work they would have added support for JPEGs
direct).
So ArtWorks it has to be: I'm not volunteering myself -- too much to do at
present.
> I did further experiments with other graphic formats and am surprised to
> find that Draw also accepts PNG -- very welcome
That will be ROOL Draw benefitting from the ImageFile_Convert stuff which was
added to Select. What actually happens is that the PNG is silently converted
to a Sprite when you load it, so it's not surprising that it then works in
Impression as the Sprite would have too. As far as I know ROOL did not add
PNGs to the Draw file format.
> Curiously, ROL's Draw 2.27 does seem to run on the Iyonix (Ro 5.18) but
> dropping a PNG into it produces error "Draw cannot load this"; I guess some
> other support module is involved.
That is consistent with what I just said above.
--
Matthew Phillips
Durham
on 11 Apr 2013 Jim Nagel wrote:
> Matthew Phillips wrote on 11 Apr:
> > Why do you need to wrap the JPEG in an ArtWorks file particularly?
> > Could you not put the JPEG inside a Draw file instead? Surely Draw
> > files can be put into Impression documents?
>
> > If Draw would do, the format is fully documented and it would be a much
> > quicker job for a developer. In fact, we already have most of the necessary
> > code lying around here as this is exactly the method DrawPrint uses to
> > support printing JPEGs.
>
> That sounds promising! You're right: it doesn't need to be Artworks
> particularly, if the openly-documented Draw could be made to do the
> job.
From what David Holden says I realise that Impression must be rendering the
> Matthew Phillips wrote on 11 Apr:
> > Why do you need to wrap the JPEG in an ArtWorks file particularly?
> > Could you not put the JPEG inside a Draw file instead? Surely Draw
> > files can be put into Impression documents?
>
> > If Draw would do, the format is fully documented and it would be a much
> > quicker job for a developer. In fact, we already have most of the necessary
> > code lying around here as this is exactly the method DrawPrint uses to
> > support printing JPEGs.
>
> That sounds promising! You're right: it doesn't need to be Artworks
> particularly, if the openly-documented Draw could be made to do the
> job.
Draw file itself using the Draw module calls. Impression of course predates
DrawFile_Render and handling JPEG objects in Draw files must never have been
added (if they had done that work they would have added support for JPEGs
direct).
So ArtWorks it has to be: I'm not volunteering myself -- too much to do at
present.
> I did further experiments with other graphic formats and am surprised to
> find that Draw also accepts PNG -- very welcome
added to Select. What actually happens is that the PNG is silently converted
to a Sprite when you load it, so it's not surprising that it then works in
Impression as the Sprite would have too. As far as I know ROOL did not add
PNGs to the Draw file format.
> Curiously, ROL's Draw 2.27 does seem to run on the Iyonix (Ro 5.18) but
> dropping a PNG into it produces error "Draw cannot load this"; I guess some
> other support module is involved.
--
Matthew Phillips
Durham
C J Craig
Apr 12, 2013, 4:03:46 AM4/12/13
to
> C J Craig wrote on 11 Apr:
>> My version of Impression Publisher (4.11) will accept small JPEGS
[snip]
>> My version of Impression Publisher (4.11) will accept small JPEGS
> Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
> Impression frame brings up this familiar old error message:
> In your example "Beagle sitting" it is at 200 dpi. I printed it and re
> scaned at 100. It now loads directly into a blank impression frame.
Example
http://www.skipton.demon.co.uk/Graphics/new.zip
Chris
Martin Bazley
Apr 12, 2013, 7:19:35 AM4/12/13
to
The following bytes were arranged on 11 Apr 2013 by Jim Nagel :
> I did further experiments with other graphic formats and am surprised
> to find that Draw also accepts PNG -- very welcome: Martin W hasn't
> yet given in to requests and added PNG support to Artworks. Moreover,
> this drawfile CAN be dropped into an Impression frame, the PNG
> appears, *and* Impression's "Alter graphic" dialogue actually shows
> the *resolution* of the PNG.
> This rates as Discovery of the Month! From now on I shall use PNGs
> in the magazine instead of JPegs in situations where JPegs acquire
> unpleasant blobs -- particularly certain screenshots.
This is a feature of ROL's OS, not Draw, or Impression. The PNG is
transparently converted to a sprite when you drag it into Draw. At no
point have you been viewing or manipulating a PNG.
Draw can load sprites, and has always been able to. Impression can,
presumably, display sprites. You would get exactly the same result with any
other format supported by the ImageFileConvert module, such as TIFF.
You wouldn't get the same result with a JPEG, because Draw supports
those natively, and so doesn't bother asking the OS to convert it into a
format it can handle.
The obvious question here is, in the case of your screenshots, why on
earth are you using sprites converted to PNGs converted to sprites,
instead of just dragging in the sprites?
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================
> I did further experiments with other graphic formats and am surprised
> to find that Draw also accepts PNG -- very welcome: Martin W hasn't
> yet given in to requests and added PNG support to Artworks. Moreover,
> this drawfile CAN be dropped into an Impression frame, the PNG
> appears, *and* Impression's "Alter graphic" dialogue actually shows
> the *resolution* of the PNG.
> This rates as Discovery of the Month! From now on I shall use PNGs
> in the magazine instead of JPegs in situations where JPegs acquire
> unpleasant blobs -- particularly certain screenshots.
transparently converted to a sprite when you drag it into Draw. At no
point have you been viewing or manipulating a PNG.
Draw can load sprites, and has always been able to. Impression can,
presumably, display sprites. You would get exactly the same result with any
other format supported by the ImageFileConvert module, such as TIFF.
You wouldn't get the same result with a JPEG, because Draw supports
those natively, and so doesn't bother asking the OS to convert it into a
format it can handle.
The obvious question here is, in the case of your screenshots, why on
earth are you using sprites converted to PNGs converted to sprites,
instead of just dragging in the sprites?
--
__<^>__ "Did you know that polar bears stay white all year round? ...The
/ _ _ \ white colour makes them less visible to the seals and penguins
( ( |_| ) ) they hunt." - Nelson Thornes AQA-endorsed GCSE science textbook
\_> <_/ ======================= Martin Bazley ==========================
Martin Wuerthner
Apr 12, 2013, 4:08:19 PM4/12/13
to
C J Craig <Ch...@skipton.demon.co.uk> wrote:
> My version of Impression Publisher (4.11) will accept small JPEGS 100,000
> bytes but 1 Meg, You get egg timer then screen goes black and computer can
> not be re-started from the keyboard. Trys a low res screen mode but just
> black??.. Perhaps it because I have Artworks 2 modules installed allowing
> the JPEGS to transfer to Impression??
No, what happens is that you have CC's JPEG loader installed, which converts
> My version of Impression Publisher (4.11) will accept small JPEGS 100,000
> bytes but 1 Meg, You get egg timer then screen goes black and computer can
> not be re-started from the keyboard. Trys a low res screen mode but just
> black??.. Perhaps it because I have Artworks 2 modules installed allowing
> the JPEGS to transfer to Impression??
the JPEG to a sprite when it is dropped into Impression. That is not very
useful even for moderately sized JPEGs. Impression cannot embed compressed
JPEG files in its documents, but it can embed ArtWorks files, which in turn
can contain compressed JPEGs.
--
Martin Wuerthner MW Software http://www.mw-software.com/
------- RISC OS Software for Design, Printing and Publishing --------
cfe...@freeremoveuk.com.invalid
Apr 12, 2013, 4:22:30 PM4/12/13
to
In message <mpro.ml5rxv0007...@mw-software.com>
Thanks
--
Colin Ferris Cornwall UK
Martin Wuerthner <spam...@mw-software.com> wrote:
> C J Craig <Ch...@skipton.demon.co.uk> wrote:
>> My version of Impression Publisher (4.11) will accept small JPEGS 100,000
>> bytes but 1 Meg, You get egg timer then screen goes black and computer can
>> not be re-started from the keyboard. Trys a low res screen mode but just
>> black??.. Perhaps it because I have Artworks 2 modules installed allowing
>> the JPEGS to transfer to Impression??
> No, what happens is that you have CC's JPEG loader installed, which converts
> the JPEG to a sprite when it is dropped into Impression. That is not very
> useful even for moderately sized JPEGs. Impression cannot embed compressed
> JPEG files in its documents, but it can embed ArtWorks files, which in turn
> can contain compressed JPEGs.
Any chance of being able to embed 'PNG' files into Artworks files?
> C J Craig <Ch...@skipton.demon.co.uk> wrote:
>> My version of Impression Publisher (4.11) will accept small JPEGS 100,000
>> bytes but 1 Meg, You get egg timer then screen goes black and computer can
>> not be re-started from the keyboard. Trys a low res screen mode but just
>> black??.. Perhaps it because I have Artworks 2 modules installed allowing
>> the JPEGS to transfer to Impression??
> No, what happens is that you have CC's JPEG loader installed, which converts
> the JPEG to a sprite when it is dropped into Impression. That is not very
> useful even for moderately sized JPEGs. Impression cannot embed compressed
> JPEG files in its documents, but it can embed ArtWorks files, which in turn
> can contain compressed JPEGs.
Thanks
--
Colin Ferris Cornwall UK
Jim Nagel
Apr 12, 2013, 7:50:32 PM4/12/13
to
...
sprites, though. To check, doubleclick the graphic, then Info, and
filetype shows as sprite. Oddly, though, the PNG graphic (which is
*the PNG file icon*, not the graphic that was in my example PNG) does
say the filetype is PNG. Check that one by saving it into Artworks,
ungroup it, and it is clearly identified as a sprite.
So I expect you have some of the importer modules active in your copy
of Impression, which convert various incoming graphic formats to
sprites, and they are stored from then on *as sprites* in the document
file. To see what modules you have, go to Impression on the iconbar,
Preferences, Modules.
--
Jim Nagel www.archivemag.co.uk
>> C J Craig wrote on 11 Apr:
>>> My version of Impression Publisher (4.11) will accept small JPEGS
>>> My version of Impression Publisher (4.11) will accept small JPEGS
Jim Nagel wrote:
>> Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
>> Impression frame brings up this familiar old error message:
C J Craig wrote on 12 Apr:
>> Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
>> Impression frame brings up this familiar old error message:
> In your example "Beagle sitting" it is at 200 dpi. I printed it and re
> scaned at 100. It now loads directly into a blank impression frame.
> Example: http://www.skipton.demon.co.uk/Graphics/new.zip
All the graphics in your Impression document have been converted to
> scaned at 100. It now loads directly into a blank impression frame.
> Example: http://www.skipton.demon.co.uk/Graphics/new.zip
sprites, though. To check, doubleclick the graphic, then Info, and
filetype shows as sprite. Oddly, though, the PNG graphic (which is
*the PNG file icon*, not the graphic that was in my example PNG) does
say the filetype is PNG. Check that one by saving it into Artworks,
ungroup it, and it is clearly identified as a sprite.
So I expect you have some of the importer modules active in your copy
of Impression, which convert various incoming graphic formats to
sprites, and they are stored from then on *as sprites* in the document
file. To see what modules you have, go to Impression on the iconbar,
Preferences, Modules.
--
Jim Nagel www.archivemag.co.uk
Jim Nagel
Apr 12, 2013, 7:50:05 PM4/12/13
to
Martin Bazley wrote on 12 Apr:
> The following bytes were arranged on 11 Apr 2013 by Jim Nagel :
>> I did further experiments with other graphic formats and am surprised
>> to find that Draw also accepts PNG -- very welcome: Martin W hasn't
>> yet given in to requests and added PNG support to Artworks. Moreover,
>> this drawfile CAN be dropped into an Impression frame, the PNG
>> appears, *and* Impression's "Alter graphic" dialogue actually shows
>> the *resolution* of the PNG.
>> This rates as Discovery of the Month! From now on I shall use PNGs
>> in the magazine instead of JPegs in situations where JPegs acquire
>> unpleasant blobs -- particularly certain screenshots.
> This is a feature of ROL's OS, not Draw, or Impression. The PNG is
> transparently converted to a sprite when you drag it into Draw. At no
> point have you been viewing or manipulating a PNG.
Unfortunately, Martin B is right, as I had already discovered when I
belatedly compared the size of my original PNG example (3K) with the
size of the drawfile after dropping that PNG into it: 124K. So Draw
had indeed expanded the PNG into a sprite. I hereby strip my
Discovery of the Month of its medals and honours.
> The obvious question here is, in the case of your screenshots, why on
> earth are you using sprites converted to PNGs converted to sprites,
> instead of just dragging in the sprites?
The point of the utility I'm wishing for is to keep the filesize low
by finding a way to keep JPegs and PNGs in their native state when
brought into Impression. Artworks provides a route for JPegs, and
that's what I use -- I'd love a utility to handle the repetitive
manual steps. Would be very welcome if Artworks handled PNGs too.
--
Jim Nagel www.archivemag.co.uk
> The following bytes were arranged on 11 Apr 2013 by Jim Nagel :
>> I did further experiments with other graphic formats and am surprised
>> to find that Draw also accepts PNG -- very welcome: Martin W hasn't
>> yet given in to requests and added PNG support to Artworks. Moreover,
>> this drawfile CAN be dropped into an Impression frame, the PNG
>> appears, *and* Impression's "Alter graphic" dialogue actually shows
>> the *resolution* of the PNG.
>> This rates as Discovery of the Month! From now on I shall use PNGs
>> in the magazine instead of JPegs in situations where JPegs acquire
>> unpleasant blobs -- particularly certain screenshots.
> This is a feature of ROL's OS, not Draw, or Impression. The PNG is
> transparently converted to a sprite when you drag it into Draw. At no
> point have you been viewing or manipulating a PNG.
belatedly compared the size of my original PNG example (3K) with the
size of the drawfile after dropping that PNG into it: 124K. So Draw
had indeed expanded the PNG into a sprite. I hereby strip my
Discovery of the Month of its medals and honours.
> The obvious question here is, in the case of your screenshots, why on
> earth are you using sprites converted to PNGs converted to sprites,
> instead of just dragging in the sprites?
by finding a way to keep JPegs and PNGs in their native state when
brought into Impression. Artworks provides a route for JPegs, and
that's what I use -- I'd love a utility to handle the repetitive
manual steps. Would be very welcome if Artworks handled PNGs too.
--
Jim Nagel www.archivemag.co.uk
C J Craig
Apr 13, 2013, 3:32:44 AM4/13/13
to
In message <7d0c773...@nails.abbeypress.net>
> So I expect you have some of the importer modules active in your copy
> of Impression, which convert various incoming graphic formats to
> sprites,
[snip]
> Preferences, Modules.
Shows no modules found!
I did have a floppy called Impression business supplement but it did
not include graphic loaders. Nice to still be finding new features in
a prog one has used for 21 yrs!
Jim Nagel <jimne...@abbeypress.co.uk> wrote:
> ...
>>> C J Craig wrote on 11 Apr:
>>>> My version of Impression Publisher (4.11) will accept small JPEGS
> Jim Nagel wrote:
>>> Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
>>> Impression frame brings up this familiar old error message:
> C J Craig wrote on 12 Apr:
>> In your example "Beagle sitting" it is at 200 dpi. I printed it and re
>> scaned at 100. It now loads directly into a blank impression frame.
>> Example: http://www.skipton.demon.co.uk/Graphics/new.zip
> All the graphics in your Impression document have been converted to
> sprites, though.
[snip]
> ...
>>> C J Craig wrote on 11 Apr:
>>>> My version of Impression Publisher (4.11) will accept small JPEGS
> Jim Nagel wrote:
>>> Well, here on Publisher Plus 5.13, dropping a small JPeg into a blank
>>> Impression frame brings up this familiar old error message:
> C J Craig wrote on 12 Apr:
>> In your example "Beagle sitting" it is at 200 dpi. I printed it and re
>> scaned at 100. It now loads directly into a blank impression frame.
>> Example: http://www.skipton.demon.co.uk/Graphics/new.zip
> All the graphics in your Impression document have been converted to
> sprites, though.
> So I expect you have some of the importer modules active in your copy
> of Impression, which convert various incoming graphic formats to
> sprites,
> Preferences, Modules.
Shows no modules found!
I did have a floppy called Impression business supplement but it did
not include graphic loaders. Nice to still be finding new features in
a prog one has used for 21 yrs!
Martin Wuerthner
Apr 15, 2013, 10:23:52 AM4/15/13
to
ArtWorks file in Impression you would also need an updated ArtWorks renderer
module.
Jim Nagel
Apr 15, 2013, 2:08:19 PM4/15/13
to
Martin Wuerthner <spam...@mw-software.com> wrote:
>>> ... Impression cannot embed compressed JPEG files in its documents,
Being able to drop a JPeg or a PNG directly onto Artworks on the
iconbar would be welcome too -- have always been able to do that with
sprites.
The result is an Artworks "page" just big enough for the dropped-in
graphic, with the corollary that the graphic is positioned at (0,0) on
the page -- and that means that after importing the Artwork to an
Impression frame, Impression's "Alter graphic" dialogue shows
meaningful coordinates.
While tinkering with the guts of all this, might it also be
possible for the resolution info to be made available to Impression so
that the "Alter graphic > Info" dialogue shows a meaningful figure?
(The "dpi" value is essential to know before printing.) Curiously,
Impression shows the "dpi" when dealing with a sprite wrapped in a
drawfile, but not for a sprite wrapped in an Artworks file.
>>> ... Impression cannot embed compressed JPEG files in its documents,
>>> but it can embed ArtWorks files, which in turn can contain compressed
>>> JPEGs.
>>> JPEGs.
cfe...@freeRemoveuk.com.invalid wrote:
>> Any chance of being able to embed 'PNG' files into Artworks files?
Martin Wuerthner wrote on 15 Apr:
>> Any chance of being able to embed 'PNG' files into Artworks files?
> Sounds like a nice feature. Of course, if you wanted to render the resulting
> ArtWorks file in Impression you would also need an updated ArtWorks renderer
> module.
Lookin' forward to that!
> ArtWorks file in Impression you would also need an updated ArtWorks renderer
> module.
Being able to drop a JPeg or a PNG directly onto Artworks on the
iconbar would be welcome too -- have always been able to do that with
sprites.
The result is an Artworks "page" just big enough for the dropped-in
graphic, with the corollary that the graphic is positioned at (0,0) on
the page -- and that means that after importing the Artwork to an
Impression frame, Impression's "Alter graphic" dialogue shows
meaningful coordinates.
While tinkering with the guts of all this, might it also be
possible for the resolution info to be made available to Impression so
that the "Alter graphic > Info" dialogue shows a meaningful figure?
(The "dpi" value is essential to know before printing.) Curiously,
Impression shows the "dpi" when dealing with a sprite wrapped in a
drawfile, but not for a sprite wrapped in an Artworks file.
Martin Wuerthner
Apr 16, 2013, 7:45:17 AM4/16/13
to
Jim Nagel <jimne...@abbeypress.co.uk> wrote:
> While tinkering with the guts of all this, might it also be
> possible for the resolution info to be made available to Impression so
> that the "Alter graphic > Info" dialogue shows a meaningful figure? (The
> "dpi" value is essential to know before printing.) Curiously, Impression
> shows the "dpi" when dealing with a sprite wrapped in a drawfile, but not
> for a sprite wrapped in an Artworks file.
That happens because Impression can look inside a Drawfile to see whether it
> While tinkering with the guts of all this, might it also be
> possible for the resolution info to be made available to Impression so
> that the "Alter graphic > Info" dialogue shows a meaningful figure? (The
> "dpi" value is essential to know before printing.) Curiously, Impression
> shows the "dpi" when dealing with a sprite wrapped in a drawfile, but not
> for a sprite wrapped in an Artworks file.
only contains a single sprite and thus find out about its width and height
in pixels, but it cannot look inside an ArtWorks file. The ArtWorks renderer
could make that information available, but Impression would have to be
updated to use it.
0 new messages