Index » PageStream Support » General » Re: Lulu and LPI/screen frequency
Sign in to add a comment. Pages: 1
2013-03-02 15:56:22 CT #1
Brent W. Santin
From: Canada
Registered: 2007-11-02
Posts: 105

Hi Tim,

You might remember I printed some children's books via Lulu about six months ago.

These were heavily image intensive. I didn't work in lines per inch, but rather imported images into PageStream at various dpi.

These were output to PDFs and uploaded to Lulu.

I did two books using 300 dpi images. Another book was done using 600dpi image. I actually had intended to downscale the images to 300 dpi when exporting to PDF with PageStream - but PageStream's PDF engine is broken and doesn't resample images to different dpi's even when you ask it to in the PDF exporter.

Anyway, I had no problem with the 300dpi images. Initially, I also had no problem with the book that used 600dpi images. I was initially able to order and did receive several of the 600dpi image books. They looked great.

Then a friend ordered them a few weeks later and I got an "error" e-mail from Lulu.com saying there was a problem with the order. It could not be fulfilled.

After talking to Lulu.com staff online, I discovered that the initial orders for the 600dpi book (the one that was delivered) was printed by their printer in Canada. The second order (the one that failed) was done be their printer in the USA (maybe they have more than one printing service in the USA). The problem was that the Canadian printing service was using hardware that could handle my large images, the USA printer was using hardware that could not handle my large images without the printer choking and having a "timeout" error.

So I resized all the images in my 600dpi book to 300dpi manually - reimported them into PageStream manually (which was not that easy as PageStream resized them all wrong - the frame around the image would be correct, but the image in the frame would be too small). Then I re-uploaded this new 300dpi book to Lulu.com and haven't had any problems since.

I haven't filed a bug report to PageStream about the faulty image re-sizing because it was an exhausting effort and I haven't had the energy yet. But basically it came down to - images that were cropped in PageStream would not re-import properly when you substituted the external image on disk with one of a different dpi.

But getting back to your question - I know I haven't addressed the lines-per-inch issue, but maybe my experience will shed a bit on light on the answers to your questions.

Brent

--- In PageStreamSupport@yahoogroups.com, Tim Doty <thoromyr@...> wrote:
>
> I'm finishing up a book for printing at Lulu. Actually, the book is old (last revised 1999), but I'm adding illustrations to it. And herein lies my problem. The art is grey scale and, searching lulu for information, it appears that they are using something like 60-80 lpi, but certainly not much more than 100 lpi -- which is simply not enough to capture detail. Even my personal printer can manage 180 lpi so I'm not sure what gives.
>
> The thing is, none of this information is official. Lulu refuses to say anything about the printers they use, their specs or anything. I've put in a support request and haven't heard anything from them. (It looks like they only provide support for paid-support accounts.) What they *have* said (on their site) is nonsensical. For example, they tell people to save grey scale images as RGB to avoid the "pixelation" from low lpi. Users who have a clue have suggested that line art be submitted as high resolution black and white, but that is only suitable for pen-and-ink line drawings.
>
> I know some people here have used Lulu and I'm hoping that someone has specific experience they can share. I've tested converting an image to black and white. This loses a lot of detail, of course, but for the one image would be acceptable if I have to go that route. Even there, Lulu says they want artwork at 300 dpi and it is always possible they'll just scale everything to that resolution, even if I provide higher resolution images. At 600 dpi the black and white has acceptably minimal jagged edges on slanted lines, 300 dpi just doesn't look good.
>
> So, any information to be shared? Advice to give? Incidentally, I am deliberately doing grey scale -- color is not what I want for this.
>
> Tim Doty
>

2013-03-02 16:09:18 CT #2
Brent W. Santin
From: Canada
Registered: 2007-11-02
Posts: 105

Hi Tim, and just to add - the images I was using in my children's books were detailed mazes with tiny things to find. The detail at both 600dpi and 300dpi was satisfactory for this purpose (no visible jaggies). I was pleased.

Brent


2013-03-02 11:59:00 CT #3
Tim Doty
From: United States
Registered: 2006-02-06
Posts: 2939

Hi Brent,

Yes, thanks, that was very helpful. And interesting. In the forums there was one person advocating B&W images be provided at 600dpi, and in context these would be full page images, which sounds like it would be a problem. And yet no one from Lulu says anything. That thread was either responses to an official post or linked from an official post about printing advice (that had the 'save grey scale as color to avoid pixelation' advice).

So, in part, it sounds like Lulu doesn't answer because they don't know. One set of constraints when using this printer, and a different set with another printer, and if they use more than two…

In any case, your experience is certainly relevant and thanks for sharing that again.

As to the PgS problems: I thought (at least on the latest OS X) it did resample the image. I'll have to double check that.

The reimporting into PgS… it kind of depends on how you do it. If the images were left as external and simply edited the problem is PgS thinks it is so many pixels per inch and so you end up with (in your case) it taking up half the space in each dimension.

If you use the replace graphic script it should work correctly. Of course, that is replacing it one image at a time. Doing an automated replace with correct sizing shouldn't be that hard to script -- and would take less time to script than do manually if many images were involved.

Just something to think about for the future.

Tim Doty

On Mar 2, 2013, at 9:56 AM, Brent <woodenflutes@yahoo.ca> wrote:

> Hi Tim,
>
> You might remember I printed some children's books via Lulu about six months ago.
>
> These were heavily image intensive. I didn't work in lines per inch, but rather imported images into PageStream at various dpi.
>
> These were output to PDFs and uploaded to Lulu.
>
> I did two books using 300 dpi images. Another book was done using 600dpi image. I actually had intended to downscale the images to 300 dpi when exporting to PDF with PageStream - but PageStream's PDF engine is broken and doesn't resample images to different dpi's even when you ask it to in the PDF exporter.
>
> Anyway, I had no problem with the 300dpi images. Initially, I also had no problem with the book that used 600dpi images. I was initially able to order and did receive several of the 600dpi image books. They looked great.
>
> Then a friend ordered them a few weeks later and I got an "error" e-mail from Lulu.com saying there was a problem with the order. It could not be fulfilled.
>
> After talking to Lulu.com staff online, I discovered that the initial orders for the 600dpi book (the one that was delivered) was printed by their printer in Canada. The second order (the one that failed) was done be their printer in the USA (maybe they have more than one printing service in the USA). The problem was that the Canadian printing service was using hardware that could handle my large images, the USA printer was using hardware that could not handle my large images without the printer choking and having a "timeout" error.
>
> So I resized all the images in my 600dpi book to 300dpi manually - reimported them into PageStream manually (which was not that easy as PageStream resized them all wrong - the frame around the image would be correct, but the image in the frame would be too small). Then I re-uploaded this new 300dpi book to Lulu.com and haven't had any problems since.
>
> I haven't filed a bug report to PageStream about the faulty image re-sizing because it was an exhausting effort and I haven't had the energy yet. But basically it came down to - images that were cropped in PageStream would not re-import properly when you substituted the external image on disk with one of a different dpi.
>
> But getting back to your question - I know I haven't addressed the lines-per-inch issue, but maybe my experience will shed a bit on light on the answers to your questions.
>
> Brent
>
> --- In PageStreamSupport@yahoogroups.com, Tim Doty wrote:
> >
> > I'm finishing up a book for printing at Lulu. Actually, the book is old (last revised 1999), but I'm adding illustrations to it. And herein lies my problem. The art is grey scale and, searching lulu for information, it appears that they are using something like 60-80 lpi, but certainly not much more than 100 lpi -- which is simply not enough to capture detail. Even my personal printer can manage 180 lpi so I'm not sure what gives.
> >
> > The thing is, none of this information is official. Lulu refuses to say anything about the printers they use, their specs or anything. I've put in a support request and haven't heard anything from them. (It looks like they only provide support for paid-support accounts.) What they *have* said (on their site) is nonsensical. For example, they tell people to save grey scale images as RGB to avoid the "pixelation" from low lpi. Users who have a clue have suggested that line art be submitted as high resolution black and white, but that is only suitable for pen-and-ink line drawings.
> >
> > I know some people here have used Lulu and I'm hoping that someone has specific experience they can share. I've tested converting an image to black and white. This loses a lot of detail, of course, but for the one image would be acceptable if I have to go that route. Even there, Lulu says they want artwork at 300 dpi and it is always possible they'll just scale everything to that resolution, even if I provide higher resolution images. At 600 dpi the black and white has acceptably minimal jagged edges on slanted lines, 300 dpi just doesn't look good.
> >
> > So, any information to be shared? Advice to give? Incidentally, I am deliberately doing grey scale -- color is not what I want for this.
> >
> > Tim Doty
> >
>
>


2013-03-02 12:02:59 CT #4
Tim Doty
From: United States
Registered: 2006-02-06
Posts: 2939

On Mar 2, 2013, at 10:09 AM, Brent <woodenflutes@yahoo.ca> wrote:

> Hi Tim, and just to add - the images I was using in my children's books were detailed mazes with tiny things to find. The detail at both 600dpi and 300dpi was satisfactory for this purpose (no visible jaggies). I was pleased.

Were those black and white? color? grey scale?

300 dpi for black and white will show some jaggies on diagonals, but 300 dpi isn't bad.

300 dpi for color is definitely fine when printing continuous tone.

300 dpi for grey scale -- it really depends on the image and the lpi. Rule of thumb is at least twice the lpi so for up to 150 lpi it will be as good as it will be. Higher resolution is basically wasted on a low lpi print.

Tim Doty
From thoromyr@mac.com Sat Mar 02 10:10:23 2013
Return-Path: <thoromyr@mac.com>
X-Sender: thoromyr@mac.com
X-Apparently-To: PageStreamSupport@yahoogroups.com
X-Received: (qmail 98662 invoked from network); 2 Mar 2013 18:10:23 -0000
X-Received: from unknown (10.193.84.150)
by m5.grp.bf1.yahoo.com with QMQP; 2 Mar 2013 18:10:23 -0000
X-Received: from unknown (HELO nk11p03mm-asmtp002.mac.com) (17.158.232.237)
by mta2.grp.bf1.yahoo.com with SMTP; 2 Mar 2013 18:10:23 -0000
X-Received: from [10.0.1.191]
(64-251-146-34-cablemodem-roll.fidnet.com [64.251.146.34])
by nk11p03mm-asmtp002.mac.com
(Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul
13 2012)) with ESMTPSA id <0MJ1007DRP53KV50@nk11p03mm-asmtp002.mac.com> for
PageStreamSupport@yahoogroups.com; Sat, 02 Mar 2013 18:10:16 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.9.8327,1.0.431,0.0.0000
definitions 13-03-02_06:2013-03-01,2013-03-02,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policyÞfault score=0 spamscore=0
ipscore=0 suspectscore! phishscore=0 bulkscore=0 adultscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001
definitions=main-1303020184
Content-type: text/plain; charset=windows-1252
MIME-version: 1.0 (Mac OS X Mail 6.2 \(1499\))
In-reply-to: <kgtdqn+c259@eGroups.com>
Date: Sat, 02 Mar 2013 12:10:15 -0600
Content-transfer-encoding: quoted-printable
Message-id: <140A370C-B5C5-4B45-9E85-0B9F9EABC244@mac.com>
References: <kgtdqn+c259@eGroups.com>
To: PageStreamSupport@yahoogroups.com
X-Mailer: Apple Mail (2.1499)
X-Originating-IP: 17.158.232.237
X-eGroups-Msg-Info: 1:12:0:0:0
From: Tim Doty <thoromyr@mac.com>
Subject: Re: [PageStreamSupport] Re: PageStream 5.0.5.9 in MacOS 10.8.2
X-Yahoo-Group-Post: member; u39834679; y=3IsX1xpsefUJk6--3hePYHI7UgW5Zh15CQtvnyFS4Y9VPVo
X-Yahoo-Profile: neinspam

On Mar 2, 2013, at 11:44 AM, sdevries30 <sjoerd.de.vries@me.com> wrote:

> Thanks Tim,
>
> I am a normal user so don't ask me about terminal, checksum ect.

well, that limits how much can be learned about the problem to narrow it down and find it. There are two issues: 1) PgS won't run for you and 2) it runs fine for Deron -- if he can't reproduce a problem it makes very hard.

> When i double click on the program it bounce one time shortly in the doc (very short)
> No crash dialog
> Right clicking, and choose open has the same result
>
> I deleted the prefs in the folder you have written but the prefs are not returning back after trying to start the program

I don't recommend deletion, just rename. That way it can be restored, but deleting achieves the purpose of eliminating something in prefs being a problem.

> I have downloaded the program several times but same result.

The md5 check is just a thought -- not a particularly likely one. I believe there is at least one other user who has the same problem. Its just really hard to trouble shoot this sort of thing remotely. As I noted, PgS works just fine for me.

I realize you aren't versed on the terminal, but that I did provide example commands so you could cut and paste. I suspect that PgS is just terminating without an error message, but there are two ways to tell: launch it from the terminal or use Console (under /Applications/Utilities) to find. The latter avoids using the command line, but at the expense of being a lot more work -- particularly if you aren't familiar with logs and OS X's viewer.

I'd be happy to take an in-person look, but I doubt we are anywhere near each other. I'm in mid-Missouri which is a long way from most of the world… There are ways to help work around that as well, if you are interested. But such a discussion would be best off-list.

Tim Doty


>
> --- In PageStreamSupport@yahoogroups.com, Tim Doty wrote:
> >
> > I'm sure Deron wants to resolve the issue, but it is hard when it can't be replicated. PgS works just fine for me in OS X 10.8.2 (which is a blessing because I'm back to using it more again, the 64-bit linux version still crashes on copy/paste operations).
> >
> > Not that I think I have any answers, but its been a while since the topic was discussed -- you say "It just don't start" -- exactly what does that mean?
> >
> > Do you get an application crash dialog? If so, have you sent Deron the crash log?
> >
> > Does the app icon in the doc bounce for a while, then stop without anything ever opening?
> >
> > Have you tried removing the PgS prefs? (rename ~/Library/Application Support/PageStream5 and then run)
> >
> > If you run from the terminal are there any messages? (open Terminal and run "/Applications/PageStream.app/Contents/MacOS/PageStream5Pro" assuming PgS is in the Applications folder)
> >
> > Have you tried right clicking/control-clicking on PgS and selecting 'Open' from the popup menu?
> >
> > What is the md5 sum of the executable and libraries? E.g.,
> >
> > md5 -q /Applications/PageStream.app/Contents/MacOS/PageStream5Pro
> > 0394072c8f5627a5f3faf2cf9815028a
> >
> > (perhaps better for a quick overall comparison would be to zip your PgS app (right/control click, select compress) and do an md5sum of that.
> >
> > Tim Doty
> >
> > On Mar 2, 2013, at 7:33 AM, sdevries30 wrote:
> >
> > > Deron,
> > >
> > > When do we see a working version?
> > > I am waiting now for a half year, and want to use your program, but I am back to
> > > for a long time to Pages.
> > >
> > > It just don't start!
> > >
> > >
> >
>
>


2013-03-03 15:30:39 CT #5
Brent W. Santin
From: Canada
Registered: 2007-11-02
Posts: 105

--- In PageStreamSupport@yahoogroups.com, Tim Doty <thoromyr@...> wrote:
>
> On Mar 2, 2013, at 10:09 AM, Brent <woodenflutes@...> wrote:
>
> > Hi Tim, and just to add - the images I was using in my children's books were detailed mazes with tiny things to find. The detail at both 600dpi and 300dpi was satisfactory for this purpose (no visible jaggies). I was pleased.
>
> Were those black and white? color? grey scale?
>
> 300 dpi for black and white will show some jaggies on diagonals, but 300 dpi isn't bad.
>
> 300 dpi for color is definitely fine when printing continuous tone.
>
> 300 dpi for grey scale -- it really depends on the image and the lpi. Rule of thumb is at least twice the lpi so for up to 150 lpi it will be as good as it will be. Higher resolution is basically wasted on a low lpi print.
>
> Tim Doty

Hi Tim,

The images for my children's books were all full colour RGB images. I can't say that my eye could notice any difference from the original print at 600dpi and the later print at 300dpi (I used a good downscaling algorithm in Irfanview to reduce the 600dpi images to 300dpi).

I was printing a 9x7 landscape book....and the full colour images appeared on every right hand page, with text and smaller images on the left. The covers were all done at 300dpi in full bleed.

You can preview them here (sometimes it takes a while for the previews to show up):
http://www.lulu.com/spotlight/woodenflutes

Although I don't think the previews will help you, because they are merely quick lo-res renders from the PDF the author uploads.

The funny thing is, that somewhere on Lulu's website I read that they will accept images up to 600dpi. But obviously, if their hardware chokes on this - I wouldn't suggest it. I would say, in Lulu's defense, that that my book was severely image intensive (lots of images on every page at high resolution). I'm sure a book with a few smaller diagrams at 600dpi won't choke Lulu's printers the way mine did.

It's fairly cheap to upload an early draft of your book and print a "test" copy (cost of printing plus shipping - for my 60 page full colour book it was about $25). You could probably even upload just a few pages from your book and request a "test copy" and not make this publicly available, then delete this lulu "project" (which is what they call it) when you go to upload the real book.


2013-03-03 15:32:53 CT #6
Brent W. Santin
From: Canada
Registered: 2007-11-02
Posts: 105

--- In PageStreamSupport@yahoogroups.com, Tim Doty <thoromyr@...> wrote:
>
> On Mar 2, 2013, at 10:09 AM, Brent <woodenflutes@...> wrote:
>
> > Hi Tim, and just to add - the images I was using in my children's books were detailed mazes with tiny things to find. The detail at both 600dpi and 300dpi was satisfactory for this purpose (no visible jaggies). I was pleased.
>
> Were those black and white? color? grey scale?
>
> 300 dpi for black and white will show some jaggies on diagonals, but 300 dpi isn't bad.
>
> 300 dpi for color is definitely fine when printing continuous tone.
>
> 300 dpi for grey scale -- it really depends on the image and the lpi. Rule of thumb is at least twice the lpi so for up to 150 lpi it will be as good as it will be. Higher resolution is basically wasted on a low lpi print.
>
> Tim Doty

Hi Tim,

The images for my children's books were all full colour RGB images. I can't say that my eye could notice any difference from the original print at 600dpi and the later print at 300dpi (I used a good downscaling algorithm in Irfanview to reduce the 600dpi images to 300dpi).

I was printing a 9x7 landscape book....and the full colour images appeared on every right hand page, with text and smaller images on the left. The covers were all done at 300dpi in full bleed.

You can preview them here (sometimes it takes a while for the previews to show up):
http://www.lulu.com/spotlight/woodenflutes

Although I don't think the previews will help you, because they are merely quick lo-res renders from the PDF the author uploads.

The funny thing is, that somewhere on Lulu's website I read that they will accept images up to 600dpi. But obviously, if their hardware chokes on this - I wouldn't suggest it. I would say, in Lulu's defense, that that my book was severely image intensive (lots of images on every page at high resolution). I'm sure a book with a few smaller diagrams at 600dpi won't choke Lulu's printers the way mine did.

It's fairly cheap to upload an early draft of your book and print a "test" copy (cost of printing plus shipping - for my 60 page full colour book it was about $25). You could probably even upload just a few pages from your book and request a "test copy" and not make this publicly available, then delete this lulu "project" (which is what they call it) when you go to upload the real book.


2013-03-03 15:34:15 CT #7
Brent W. Santin
From: Canada
Registered: 2007-11-02
Posts: 105

--- In PageStreamSupport@yahoogroups.com, Tim Doty <thoromyr@...> wrote:

> If you use the replace graphic script it should work correctly.

Ah ---- I didn't even know about the replace graphic script!

Brent


Sign in to add a comment. Pages: 1
Index » PageStream Support » General » Re: Lulu and LPI/screen frequency

This topic is closed due to inactivity.