Jump to content

Richard Liu

Members
  • Content Count

    207
  • Joined

  • Last visited

About Richard Liu

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Chris B, I seen several problems that seem to be regressions, i.e., fixed in the previous version, "unfixed" in the current one. How is that possible? Do your developers not perform regression tests on updates?
  2. Chris, 1.8.4 has just been released. Does it fix this problem -- incl. both issues?.
  3. Is this the case with Catalina as well, to which I still intend to upgrade?
  4. Yes, the laptop's 15.4" 2880 x 1800 and a BenQ SW271 27" 3840 x 2160.
  5. Any news on this bug yet, Chris? Is it fixed in the latest beta?
  6. This is what I'm referring to: This has been an annoying "feature" of many releases of Affinity Photo for Mac now. I believe I was told at one time that this was due to my not running the most recent version of macOS. Now that I have the time to upgrade to macOS 10.15 Catalina, I'm wondering whether this bug has since migrated to Catalina. I'm still on macOS 10.14.6 Mojave.
  7. OK Chris, thanks. When I review some of the photos that I have printed since discovering that the printing was once again working with live filters I also see discrepancies between exported .jpeg, .tiff, display in AFP and the prints produced by AFP. These differ in a different way than the examples that I sent you, e. g. a wall of a ruin that has too much black in it, almost as if the contrast might have gone crazy.
  8. Chris, Thanks. Any clues as to why the other problem, the discrepancy between an exported .tiff and a print is so crass? For the understanding of those reading this thread, I sent Chris a PDF generated in the macOS print dialog configured the same way as when I print. I can confirm the similarity between the PDF and what I see when I actually print. The .tiff that I sent him very closely resembles what I see in AFP on my monitor. The Soft proof adjustment layer configured to use the same ICC profile as I specify in the print dialog gives no hint of the discrepancy. Chris, I there a way to provide links to those uploads so people can see the problem?
  9. Chris, I've uploaded a "bunch" of files. The AFP file beginning with _DSC2980... has the behavior I described, i.e., slow to load the print dialog (64 sec.), slow to change the printer in the dialog (50 - 55 sec.) and slow to finish the print (64 sec. before the printing message disappears in AFP). With the other files I have a problem with printing that I just discovered while timing it. The timing in the print is OK (this is the one that is about as large as yours), but the printout is drastically different from what soft proof shows in AFP, not to mention how everything appears on the screen. When I export to tiff then print that from Preview, the results very closely resemble the appearance in AFP on my display. When I print directly from AFP, the result looks like the .pdf that I uploaded. I produced it by printing to PDF in the print dialog, incl. specifying the ICC profile for the printer. That is pretty much how the actual print from AFP to the printer looks. In the AFP file you see at the top a group "Soft proof & corrections". I use the stuff in here to soft proof with out of gamut stuff displayed, then use adjustments below the soft proof adjustment to correct. I rarely need to use it, but the result was no different when I did this time. The print didn't improve at all when I activated the group and the corrections but not the soft proof. It resembled the print without the corrections. What's going on?
  10. About that size. They're obviously too big to simply attach, but I could send you one if you tell me where to upload it.
  11. Aren't there also only very few NIK plugins, even in version 2, that support 32-bit processing?
  12. Thanks, @Chris B. I apologize for taking so long to reply. The print dialog appears very quickly when I open a new, blank document and immediately initiate the print. I hadn't expected otherwise. Furthermore, I expect many things in Affinity Photo execute more quickly on new blank documents than on ones that chock full of adjustment layers, live filters, masks containing many brush strokes, etc. So what do you recommend in the case that I wish to print real-life documents in Affinity Photo?
  13. @Patrick Connor Printing from Affinity Photo 1.8.3 is working as intended, and there are indeed differences between printing from Affinity Photo and exporting to, say, tiff then printing the exported file from Preview, even though the same ICC profile with which I am working in AFP is also embedded in the .tiff file, and both prints are being produced on the same printer with the same ICC printer profile. However, as I report in https://forum.affinity.serif.com/index.php?/topic/116509-printing-in-183-excruciatingly-slow/&do=findComment&comment=632335, printing from AFP is extremely slow. I assume that hardly anyone is using Print, or there is something wrong with my setup.
  14. I'm running Affinity Photo 1.8.3 on a 2018 MacBook Pro 15" Touch Bar with 32 GB of RAM under macOS 10.14.6 Mojave. Printing is excruciatingly s-l-o-w. For the print dialog even to appear took 1 min. 15 sec.! Savor that number. It means after clicking File | Print... I had to wait 1 min. 15 sec. just to see anything happen at all. Since the default printer is not the one I use for printing photos, the first thing I do in the Print dialog is change the printer. After selecting the printer in the dropdown list I had to wait 1 min. 20 sec. before the new printer's name replaced the old one's. After that I changed the ICC profile and the print quality, then clicked Print. It took 1 min. 15 sec. until the Printing message disappeared. Printing an exported .jpg or .tiff in Preview takes nowhere near as long. 2 min. 35 sec. just to change the default printer in the Print dialog!!!
  15. Very generally speaking, the way to write software than runs on several OS's is to separate the device independent logic from the device dependent operations and, for the latter to create device-dependent services (subprograms) for each OS that are invoked from the device independent logic in a device-agnostic way. This is likely less the problem than testing changes to those services to ensure that everything that invokes them still runs properly. Many so-called regression tests can be automated -- indeed, good software is designed from the very beginning to be "testable" --, but those that cannot can be very time consuming to test, and are susceptible to tester inattention/fatigue. Remember, too, that many services invoked by the software's are supplied by the purveyor of the OS, and some of them tend to make changes to their OS even after the final release candidate of a new version has been sent to developers.
×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.