meridian360

And furthermore, I *did* search for why AD v2 is still using rich blacks and not 100k. With no relevant solutions/results in google. So I went to the forums and made a post.

And it's responses like this that don't help anyone. Seriously... Starting with..."Why..." does. not. help. Period. It's like asking "Why would you WANT 100K?" If there are other threads, just link to them and be done with it. Please. Thank you. ------ I started "another" thread because when I want to give feedback, my first reaction is to give Affinity feedback. NOT search yet another forum for another unanswered post. And the only way Affinity allows to contact them "directly" is through these user forums. So, I'm submitting *MY* feedback. If it's annoying, well, it should be! They haven't fleshed out their feature set yet, which is annoying to users! Something something...Squeaky wheel. If it's been answered or Affinity is working on it, then by goodness sakes, they can respond --on the record-- and lock the thread. Otherwise, redundant threads only points out how pointless it is to use of forums threads as "feedback". Cheers.

And maybe the bigger problem is that Affinity has no real feedback system. Just these forums. You can make a post and put it out in the ether. But there's never any indication if the dev teams even acknowledge your 'feedback' or problem. That's considerably more frustrating, folks.

Please Affinity, for the love all things binary, please let us change the default 'black' to 100K, especially when the document settings are already in CMYK!! Why continue to punish (some of) us users by having the default black a "rich" black? It's annoying as heck to constantly have to change any new black objects or type, even imported stuff back to just K. Getting rid of the "rich" black is costing me time. Just set CMYK documents' black to K. I want to set black as 100K. Just K. K. Ok? Please?

Agreed. Let's hope v2 continues to improve. I notice that even snapping isn't the same instant satisfaction that v1 had (?). Which is one the things AD does *so* much better than--ahem--that other app. And it's just odd that you can still manipulate and/or interact with things in locked layers. Hopefully, just bugs and not UX decisions by Serif. I know they can't 1:1 copy the subscription beast. I just want to AD to be faster from a workflow standpoint, so I can use it for more projects. There's still too many hoops to jump through. It's getting there, though. Cheers.

I know that now. That why I said I found a scenario where that "Select a Layer" UI/UX technique fails. Just clicking on the Layer doesn't allow for things like Boolean operations, because it's not selection the objects, it's selecting the layers, but at the same time propagating the styles to its offspring objects. This is something Adobe came up with years and years ago and there's reasons why it doesn't always work in real world applications. The Cmd+A does work for non-style operations, but *still* does not show which *individual* object are selected. That's my point. If you're zoomed in, you will not know if you what and/or if you have the correct objects selected. The Cmd+A does allow for the Boolean operation to work. But my Glory be! It does show the outlines. It sit corrected!! Ok, onward! Thanks for the bonk on the head to get me in the right direction! Last point, and I think this is a bug. Selecting the Same. I tried that with Same Stroke weight > Equal. -- But even with the target layer the only one selected and Edit all Layers turned OFF, ADv2 still selected objects in a Hidden and Locked layer! Any ideas on that? This is all part of my sorting data from a GIS output into "final" layers to make a map. Different classes of stuff is exported and the GIS doesn't always export everything into tidy layers. We have to do that manually. Thus, selecting "by stroke weight or color" and then dumping it into our own layers. Thanks for all the hand holding!

Ok, just found a scenario that the "Select a Layer" to get the Objects on the Layer does not work. What about when you want to make a compound object out of all those objects on the layer? Selecting the Layer from the above conversation works for color (etc) attributes but not boolean operations. I still had to select all the objects by scrolling and shift-clicking in the Layer Panel to be able to do a Boolean operation (Add). Any ideas?

Now that I can handle, even if it's counter intuitive to 20+ years of Freehand and AI UI/UX experience. It still needs to show that what objects that "Layer Selection" is being applied to before you change the attributes, but it's something. It's still not perfect, but at least it's a one-click solution to applying attributes to all the objects in a layer. Thanks.

Hi Walt, Yup, ok.. that's the difference in reality vs expectation. What I *want* is to select all the Objects in the layer. I want to do that with one, quick UI operation (like the clicking on the layer would be). So if clicking on the Layer only selects the Layer and not the Objects, then that doesn't work (for me). Ex: I want to change all Highways from Red 4pt to Blue 3pt. I want to be able to click the Layer, which would select all the objects, then go to the Color panel and change it to Blue; then change the Stroke panel to 3pt. But right now, I have to go to that Layer, Expand it, Select the First object, Scroll to the bottom of the list (could be 10s of thousands of objects in a map), and Shift Click to select all the object in the layer....THEN now go to the Color panel and change it to Blue; then change the Stroke panel to 3pt. See the difference? One-Click SelectAll vs. Click-Scroll-ShiftClick. One is instant, the other is very time consuming when done over and over all day. Thanks...

Ok, problem.... When I do the click on a layer, or even Select All with the Layer Selected and Edit All Layers turned off, the Color and Stroke Panels are not reflecting what is in the layer. I have layers that have only one type of object, Ferry routes. I want to change the style of said route line to some other color and/or dash... But if I select the layer, the Color and Stroke panels don't show the current specifications of the lines?!! They just show blank lines. If I select an individual object, the Color panel updates appropriately. So, even though I can now select all the objects in a layer, how can I get ADv2 to recognize that I've done so? Sigh... The whole point is speed and efficiency. If a user has to scroll through and select stuff from the layer panel all the time, that's a huge time sink. And make Affinity Designer useless (for me) as a professional replacement for the "Other A" guys. Maybe there's legal reasons Serif can't do certain UI/UX things, but having a Color panel not update is frustrating. Cheers.

Thanks, Walt. That's a step closer to what I want. That helps, a lot. But boy, such an obscure UI/UX option. [head/palm smack] And this functionality actually works just by clicking the parent layer now. Doing so, (with your highlighted button off) selected all in that layer. Groovy. Now, is there a way/option for ADv2 to show all the selected objects *individually* and not as a whole? Such that, if you're zoomed into one area, you might not know if you've actually selected things, because well, the select box is way outside the current view window. Cheers!

In Illustrator, you can Shift-Click on a Layer, which then Select all the Object[s] on that ONE layer. Is there a way to do that with Affinity Designer v2?

Well, it was because I had opened and worked on a .svg. Even though I saved it as a .afdesign file, apparently that was enough to cause an error. When I copy and pasted the contents into a new .af file, I can print just fine. Sigh. Chalk up another Affinity UI bug.

Like the title says...press Cmd+P and Affinity Designer simply hard crashes. Poof. I recently upgraded to Mac OS 12.5 Monterey. Everything else works fine, including printing. If I save the file out as a PDF. I can print it just fine. Help?

Hi Mike, Yes, 150 dpi is a standard resolution for printing. That's our minimum, as well. And sorry, I just can't send my client's files. The goal here is to get that 65,466 pixel wide, exported at 72 dpi, to fit a map that's at 1:3,500,000 scale, at a minimum of 150 dpi final resolution. Cartographers use dpi/ppi to get our stuff to a specific Scale. That might be where we're crossing wires a bit. Once we hit the minimum dpi for printing, the actual file dimension isn't so important, as long as it is big enough for the map's coverage. We aren't making a single static image fit a layout matrix. It has to fit all sorts of other line/point/area data that was exported separately from the GIS. What is important is that it's at the right Scale. If a lake is a mile wide on the ground and the map scale is 1" = 1 Mile, then the raster better show that lake to be 1" across, whether it's made up of 150 dots or 200 dots. Our recent project had a land cover raster. For a map that's at 1:3,500,000 scale (meaning 1" on map = 3,500,000" on the ground), the satellite data can be exported at a 75 meter sample size. That is, each dot of data is a generalization of a piece of ground that is 75 meters wide/across. That raster is being exported from the GIS at 72 dpi. So for each inch of raster, there are 72 dots that are each 75 meters on the ground. So the scale of the raster is 1: 212,598.432. (see above for the formula.) That is, at 72 dpi, one inch of raster shows 212,598.212 inches across on the ground. But to get that raster to match the vector/paper map in Illustrator, we have to get it scaled down to 1:3,500,000. So, divide 3,500,000 by 212,598, then multiply the results by 72 dpi, and you get 1185.33 dpi. 1185.33 is the dpi the original 72dpi raster has be converted to in order to be at 1:3,500,000 scale. That way one inch of vector data exported separately from the GIS matches up with one inch of the raster. The file extents again doesn't matter, as long as it extends across the desired part of the map. It's not going to line up with any other file. Think of a map of the US, we use a "layer mask" to hide everything but say the land mass of the lower 48 states. The raster can be an inch bigger than the landmass's extent or it can be 30 inches wider. Doesn't matter; the mask is gonna hide the 'extra stuff'. So when I say the raster is 65,566, that never really enters the calculation, because we're not after an image size, we're after image Scale. ---- Now, this is where the decimal comes in. Maps at 60" across aren't too worried about a bit of anti-aliasing. But what is important is FIT. Does the raster "fit"? We don't want to scale the raster in Illustrator. AT ALL. AI's scale tools are archaic, even barbaric (don't get me started). Beyond that, if there are color changes in the raster, we don't want to rescale it, each time for each new output. Even though you can re-link, sometimes there's 2-3 tiffs (shading, hypsometric tints, and land cover, etc) that are all exported at the same extents. So, we want to import the file, "Set it, and forget it". The less we scale images in AI, the better. But, can we round the scale? Nope. At the size of the maps, even that 0.33 difference in DPI makes all the difference between the raster "fitting" and not fitting. We're after the doc scale, regardless of that initial dpi. The dpi just serves as means to get to our proper scale, which in this case, results in a file that just happens to be 55.315" across. See screenshot of closeups of a US Lower 48 map for the comparison. The artboard in that file is 56" across. You can see the difference when both the 1185 and the 1185.33 files are aligned the same at the west coast. The 1185 does not align at all by the time you get to the east coast. That 0.33 difference in DPI makes for a .02" difference across only 75% of the map file. It get's bigger at the far east/right edge. That 0.02" is a noticeable difference. It's amazing how quickly stuff "sticks out" when rivers don't line up to the channels/canyons! ;) ---- If I were to use AP, right now, to make the raster, it would be rounded to the 1185 dpi. And it wouldn't fit. I'd have to try to scale it manually in AI. I'd rather dance in molten lava in bare feet than do that. :) Thanks for the discussion and making me think. Hope this quick tutorial on how us map nerds get things put together. Cheers, .curt

Illustrator doc size is irrelevant, in that the tiff isn't the same document size. The hills and valleys shown on the shaded relief .tif have to match the vector rivers. Screenshot 1. Tiff file vs artboard in AI Screenshot 2. Closeup of how the raster has to align to the vectors. (Yup, it's the Grand Canyon.)

Global Mapper: Export a 75m sample to 72dpi Raster Math: Convert to map scale ((( 75m dot * 3.28084 ft/m) * 12in/ft) * 72 dpi) = raster scale Ex: 1 in of export raster is 75 m wide on the ground. To find the scale of that output (so it can be scaled later to match the map scale) you need to convert it to inches. Then since it was output at 72 dots per inch, it gets multiplied by the 72. Then find the ppi that will get the image to match the rest of the map. If map is 1:3,500,000 and your rater is ~1:212,000, then: (3,500,000/212,000)*72dpi = ~1185.33 ppi needed for raster to match vector map in Illustrator. Photoshop: Take 72dpi image, resize resolution to 1185.33 w/o resample to get the 55.315" width that matches map. Photoshop: But file size (MB) is still too big and 1185.33ppi is overkill for a large format inkjet printer, so convert with resampling to something around the 200 to 250 ppi range, which puts the file size around 400MB and still has IQ for the map. Illustrator: New 200ppi raster placed in Illustrator. (Then when map is done, an eps is saved out to PS again, run through various color RIP to get it to the Epson printer, and printed. << This last part is not my domain, and I question the need for all the RIP stuff, but again, not my concern.) So, really, it doesn't matter how they are printed. It's that they have to be a certain size to match the rest of the vector output at a very specific scale.

Nope. I need my image at a very specific inch dimension, to THREE decimal places. Which in turn makes the dpi/ppi resolution 1185.33 dpi, which AP isn't capable of. Or if I open it in AP, and try to change the Picture dimension, and have it calculate the resolution, like Photoshop can....nope. Can't do it. AP won't let you input an image size and do the resolution for you. Try this. Make a 65,566px by 41,855px tif file at 72dpi. Then try to make the image exactly 55.315" by 35.311", which results in a dpi of 1185.33 dpi. But use the AP Resize Document dialog to input the Inch size. Can't do it. Or try to put in 1185.33 dpi. Can't do it. So even if I was thrown off by the file being opened at 96dpi, which I'm admitting I was, it still can't get me to my actual target resolution. The problem has shifted from "what's with the 96?" to "Hm, AP can't do decimal resolutions". Attached are the Image Size boxes from Photoshop for the file in question. 1. Starts at 72 dpi and 65,566px wide. 2. Then set resolution to 1185.33 (which gives me a image size that exactly matches my map's scale) 3. Then if required, resample to a lower resolution for manageable file sizes, not dropping below 150ppi so it still looks good off the large format printer that's being used. But again, I appreciate the response. Thanks, .curt

Last one, I promise: Another thing that Photoshop allows, that AP does not, is to set the Document Size, which then adjusts the Resolution (to two decimal places) if resample is off. So, I can't use AP yet for my work. So close, yet so far...

Follow up: Even though putting in my target resolution works...it doesn't work. What I mean is, yes I can go straight from AP's default 96dpi to something else, like 1185 dpi... I need 1185.33 dpi to reach my print size accurately. AP won't let you put in decimal dpi; just rounds to the nearest dpi. That may be for 'obvious' reasons, but in a 60" print that last .33 dpi adds up. Photoshop lets us use decimal dpi calculations.

Did not change pixel dimensions, so in a pinch, I'm good to go. Just have to do the math. Thanks guys, .curt ps. If Affinity is 'listening', please let us set the default dpi to match our needs.

Raw file: 65,566 pixels across. Roughly 683 inches across. <---math says it opened it to 96dpi Then resize without resample: now nearly 911 inches <--- math says 72dpi. So, presumably, I could redo my math routine and get the desired result, just from a starting point of 96 dpi. Hm.

Oh, huh, AP has a built in header reader... And you're right Mike, no dpi info in the header. But then, why does AP force us to use 96 as the default? Argh. :) Thanks, .curt <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:tiff="http://ns.adobe.com/tiff/1.0/"> <tiff:BitsPerSample> <rdf:Seq> <rdf:li>8</rdf:li> <rdf:li>8</rdf:li> <rdf:li>8</rdf:li> </rdf:Seq> </tiff:BitsPerSample> <tiff:Compression>5</tiff:Compression> <tiff:ImageLength>41855</tiff:ImageLength> <tiff:ImageWidth>65566</tiff:ImageWidth> <tiff:Orientation>1</tiff:Orientation> <tiff:PhotometricInterpretation>2</tiff:PhotometricInterpretation> <tiff:PlanarConfiguration>1</tiff:PlanarConfiguration> <tiff:SamplesPerPixel>3</tiff:SamplesPerPixel> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="w"?>

Mike, Yup, I get resolution. Problem is, as with a lot of this stuff, any change introduces image quality issues. In my case, hillshading effects are affected. So if I know this is a 72 dpi image, and AP says it's 96....how did it make it 96? What do I base my math on? I'm not just concerned with output size (ie. screen/paper dimensions) but image quality. So I have to worry about the imagery not only looking good, but aligning 'perfectly' with other vector data like rivers. What "OS default"? Is 96dpi the default for AP on the Mac, because they assume that we're only building websites? They've got CMYK and Print page size defaults. But can only open things at 96? [sigh] (Not trying to be argumentative, min[d] you.) Oh, and the files are nearly 1 GB to start with, and reasonably proprietary. I'll have to dig around and see if anything else other than full on BBEdit can open image files to read the header. Alfred, Thanks for the response. See, I'm old school, still doing large format print stuff. Is the CSS web standard set at 96dpi? Are you implying that Affinity is setting 96dpi as a default because they assume we're making web images? Thanks guys! .curt

Thanks, Mike. Well, the forum system wiped my first reply...let's try again... If there isn't a header (and I think there is), then perhaps AP should ask us at what resolution we want it opened at? Similar to when you rip an eps in Photoshop. Why would AP think 96dpi is a good 'default' dpi to start with? And here's the problem: These images are background images for maps. They are exported from the GIS at set 72dpi x 72dpi dimension. Then we normally have to open them in Photoshop and change the image size without resampling to get our image dimension (ie print size) correct. Then usually, we have to go back and resize again, this time with resampling on, to get the dpi down to something reasonable (ie file MB size). So, the calculations have to be fairly precise. If my first step is to change it from 96 to 72, then it's one step too many. And of course, each image size transformation affects the 'data' in the image. In the attached screenshot from Graphic Converter v10, you can see that GC reads it just fine. And rest assured, Photoshop does as well. And there's no EXIF information in the file, at least according to GC again. And when opened in Preview (Mac OS Sierra). it shows 72 dpi, as well. (second screen shot). The only 'weird' part is that it's a GeoTIFF, but that's never mattered to a graphics program before. In conclusion, if I'm to rid myself of the 'other' app, and use AP instead, it needs to open these at the correct resolution. But again, thanks Mike for the response. I appreciate it. .curt