Forum Replies Created
-
AuthorPosts
-
Kenny H
MemberHi Alan, thanks for the reply!
So would it be safe to assume that glow & drop shadow effects in InDesign are raster effects, not vector, since you are able to add noise to them in InDesign?? I was just hoping that since those effects could introduce noise, the option for a gradient (or probably gradient feather) might do the same, even if it rendered the element as rasterized.
But I did try the 50% grey Photoshop image with noise option. We could live with this since we’d still be able to create all the different gradients needed in InDesign without having to hop back to Photoshop all the time.
I figured out that the gradient needs to be applied to the FRAME, while the image is just colored black and given a blending mode (I’m trying Overlay as assuming that would be most neutral, not introducing anything but the noise). However, with this method I seem to get a hairline around the image frame that I can’t get rid of. It doesn’t have a stroke, the image is larger than frame, there are no effects, etc. But there is a definite hairline that I can see where the gradient is white (or very light). In overprint preview mode, I am able to actually detect ink in the black channel there, so I don’t think it’s a preview issue.
If I try the ‘gradient feather’ method, I don’t get the hairline. And from what I can tell (at least on screen), it displays as smoothly as the standard gradient method.
I had just read somewhere (can’t find it now) that the gradient tool creates a gradient in a technically different manner (with better results) than creating the same gradient using the ‘Gradient Feather’ method (e.g., with a solid fill). But I imagine that might be due to it not having any transparency (and therefore being rasterized) by default compared to the gradient feather (something about the way a good RIP can interpret it). But if I am using a blending effect with my grayscale TIF, then I guess that introduces transparency into the gradient when using method 1 above anyways.
And I believe we have noticed a difference with certain printers having less issues with gradients than others. So I’m sure with proper RIPs and techniques, it may be a non-issue. We just don’t always get to choose the printer and wanted a ‘better-safe-than-sorry’ workflow here without adding hours to development.
MemberHi Coleen,
I really appreciate your taking the time to show the workaround ideas. The gradient in the footer would work well for that scenario, as long as the rows remained a consistent height I suppose (though I thought header/footer rows had to have same content). That’s good thinking!Unfortunately, what we wanted to be a transparent gradient border is the top border of each cell/row.
So in your example, the borders above the item & price cells would have the gradient rules with transparency. But this is not possible to add as either a paragraph rule or as a table border, as both just use a gradient swatch which has no transparency. I thought about embedding an object in each cell, but it would have the same issue as a paragraph rule – wouldn’t work right if text doesn’t align top (and adds a lot of complexity).
To give a better idea of what we’re doing compared to your example, our ‘Item’ column has photo thumbnails, and our ‘Price’ column has all the corresponding product details. Unfortunately, the product details can vary from maybe 2-7 lines of text, depending how how verbose the client is. So there’s no way to know the offset for the top paragraph rule, as it is constantly varying. If text was top-aligned, we’d be fine and wouldn’t have these issues. But it left too much empty space at the bottom of description cells when the content was short.
Ugh, tables. So necessary sometimes, but so frustrating as well…
Thanks!
MemberHi Colleen. Thanks for the creative thinking here!
Can you elaborate on what you mean by ‘drew a pathfinder/subtract shape to simulate a border’? I’m not sure I follow what you were doing here.
It appears you at first were saying you used a paragraph rule as a top border. That was my first thought, but unfortunately we decided the text needs to align to the middle of the table cell, not that top. Otherwise, that would have worked fine.
But I’m not sure how you were adding/applying the path with directional feather to the table cells, as that was the other thing we were trying to accomplish (though we may be able to let that one go if we must).
Thanks again for any & all help here!
MemberHey Adam. That’s a good idea, we’ll keep it in mind. Unfortunately, the border is not 100% consistent in all instances (sometimes it spans all columns, sometimes just one, etc.). So we’d still have to override in a number of places.
I’m wondering about adding an extra ‘fake’ row in-between the pages, but in a text frame off on the pasteboard (not on page). This way, at least we could keep actual table borders, which is probably safer in regards to placement and style. I’m imagining that as long as the off-page text frame was only large enough to handle one empty row, it would just be a matter of adding these rows where needed. Still seems very kludgy, but not sure how else to do this.
Thanks!
MemberHi Adam,
We could fake the top border with a stroke and then get rid of it on the top rows of pages. We would just have to be very wary of any reflow as edits are made or items are added. We would probably have to do this as a very last step before making final mechanicals.Was just hoping for something that could ‘ride’ in the flow of the table. What a frustrating little problem!
Thanks for any suggestions, though!
MemberSwell. Thanks for the reply, I appreciate it!
Any ‘creative’ workarounds I could do?? The biggest issue will be the bottom borders on the end of rows on each page as this happens all through the book. I can’t imagine anyone who’s ever used InD to layout a catalog with tables has not had a need to NOT have both top & bottom borders.
For the transparency gradients, these may only happen on a couple pages, so we may just fake it with a proper gradient object floating where the border should be. NOT an elegant or safe solution, but hopefully nothing would move these out of position.
Thanks!
-
AuthorPosts