Jump to content
You must now use your email address to sign in [click for more info] ×

dr_who

Members
  • Posts

    45
  • Joined

  • Last visited

Everything posted by dr_who

  1. Agreed. I can't wrap my head around what this has to do with "design". I understand that images beyond 32,767px are a pretty niche thing but within the UI/UX realm, you sometimes need very large sprite sheets. As things currently stand, I have to export my sprite sheets as tif files and then have them converted to png files via an online service. Which I find needlessly convoluted.
  2. Any updates on this issue? Ran into it a while ago, the same ordeal: rasterizing a group yields blurry results if there's an instance of the Unsharp Mask filter on the layer stack. While it's perfectly avoidable once you're aware of it, it can be a bit of a trap to an unsuspecting eye. Not fun discovering the issue further down the line with a project, when it's already too late.
  3. Thanks. I’m considering pulling the trigger on this one while it’s still on sale. Don’t know how it’s managed to fly under my radar up until now.
  4. Can anyone summarize the features VectorStyler has that AD lacks?
  5. Yeah, I uninstalled the whole font family and then only reinstalled the TTF version, seems to be working perfectly now. Thanks a bunch! Hopefully this is of use to others facing similar issues.
  6. I’m pretty sure I’ve got the GitHub version as the font has a couple of weight variations. Seemingly, all the weight variations have both OTF and TTF versions, the TTF versions being currently disabled according to the macOS Font Tool. Could this perhaps play into it? Thanks for the suggestions, I’ll be sure to try them out!
  7. Hi, On exporting to PDF, all texts with the font Bebas Neue become corrupted. I'm using the 'PDF (for print)' setting. Does anyone have any idea what could be causing the issue? In Publisher, the font appears as it is supposed to, it only gets corrupted during the export.
  8. Ok, so if my document is set to (for example) ’CMYK_Profile1’ and then I convert it to ’CMYK_Profile2’ during export, all my native CMYK bits will get converted as well? If that’s the case, then I’ll try and avoid doing that. Fortunately, I’ve already received the preferred profile from the printhouse and it’s very unlikely that I would have to change it to something else further down the line. As for the RGB stuff, I almost always use sRGB exclusively (unless I’m dealing with 3D rendered stuff, in which case it’s usually in the EXR/linear format) and I certainly intend to stick to that workflow this time around as well.
  9. Thanks! You've been very helpful. Aside from making sure all my settings etc. are correct, the transition from ID to Publisher has been a breeze so far. Astonishingly so, in fact.
  10. Thanks a bunch for your answer! So in my case, I do have several passthrough PDF's - and if I understood you correctly - I should therefore refrain from using the PDF/X setting? (And choose the Press Ready setting instead.) And just to be clear, even though my document is in CMYK mode, I can still import images in RGB mode? I prefer to keep my images RGB while I'm still editing and adjusting them (curves, levels, color balance etc.) and only convert them to CMYK at export. So if I've turned off the profile embedding option, Publisher should only convert the images at export and leave the native CMYK bits (essentially vector elements created within Publisher, text etc.) untouched? I still have Acrobat Pro installed, so I'll be sure to inspect my PDF with it once I'm done with the document.
  11. Hi! To cut to the chase right away - coming from InDesign - I've normally done my RGB->CMYK conversion at export, with the following settings: Color Conversion: Convert to Destination (Preserve Numbers) Destination: Whatever color profile I've received from the printhouse Profile Inclusion Policy: Don't Include Profiles How would one go about emulating the above settings in Publisher?
  12. Couldn’t agree more! I really feel for the OP. Imagine you’re on a tight deadline, having worked hard the whole day and when you’re finally about to output the deliverable pdf you’re faced with this issue... Yeah, wouldn’t make me laugh either. I love this app to death which is why this thing is really killing me. But you’re right, having a feature at your disposal that is only going to betray you in the end is bordering something I don’t even want to say out loud.
  13. That’s one option but to me, even when tracing a high-res image, the results always seem more or less wonky... Depends highly on what’s being traced, though, and is definitely worth a shot.
  14. If Inkscape supports variable width strokes, maybe export to svg without the width variations and add them in Inkscape using a high-res png as a reference in the background...? Admittedly these workarounds are getting ridiculous but such is the state of affairs currently regarding this area
  15. Well, my workflow was: export to svg in AD > open the svg file in Inkscape, do the conversion from paths to shapes (can’t recall the name of the function off the top of my head but it should be relatively easy to find), save the file > open the file in AD and carry on. But then again, my paths were relatively simple with no width variations and such. They did have rounded corners and caps, though, which seemed to survive the svg exporting just fine.
  16. The malfunctioning expanding of strokes is a long-standing issue that unfortunately saw no improvements in 1.7. It’s a critical flaw keeping a lot of us at bay for now. The only workaround is to resort to 3rd party apps like Inkscape to do the conversion.
  17. Since the free, open-source Inkscape does a good job of expanding strokes (at least in terms of not compromising the form/shape itself), there probably are freely accessible papers/info on the backend math behind it. Fortunately the folks at Affinity have acknowledged the issue and stated that now that the iPad version is out of the way, this issue will get some attention so if a fix doesn’t make it to 1.7 then maybe 1.8…? I sincerely hope so since this thing is the only thing keeping me (and a couple of others I know) at bay.
  18. Such speculations and rumors start to emerge when there is no communication. Anything’s possible when nothing is denied nor confirmed. While I agree too much time spent on responding here is away from the actual development, I think there’s a sweet spot to be found somewhere in the middle. Some of us as customers have our own realities to deal with, which aren’t limitless in terms of time and resources either. Decisions need to be made, work needs to get done. Some insight into where a given piece of software is at and where it’s likely headed to would go a long way helping us navigate all that.
  19. I’m glad to have learned that. Let’s hope the desktop Designer gets all the love it deserves from here on out
  20. The silence is deafening indeed which is the worst part of the whole shebang. I doubt anyone thinks fixing these kinds of issues is easy or quick but the complete absence of dialogue is starting to feel increasingly discouraging. Either the issue has turned out to be much worse than the casual inspection would have you believe or they just don’t care anymore.
  21. This is a long-standing issue that's been brought up time and again. I sincerely hope a fix sees the light of day eventually. In the meantime the only viable workaround is to take your path elsewhere (e.g. Inkscape), expand it and then bring it back in. Maybe it'll get promoted in the agenda if enough people voice their concerns so let's make some noise :)
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.