Jump to content

trajanmcgill

Members
  • Content count

    17
  • Joined

  • Last visited

Everything posted by trajanmcgill

  1. This was my leading theory, for a minute. I just experimented by running the .167 installer and then running the .174 installer, in the same Windows session but without ever launching the application in between, and it worked without error. Of course, I then tried to confirm it by uninstalling .174, reinstalling .167, launching the application, quitting, then running the .174 installer...and suddenly for the first time ever, I saw the installer for one version successfully update from a previous version without a reboot. So I'm still not entirely sure what is going on, unfortunately.
  2. Okay, this could be a clue. On reboot, the program folder has disappeared. It was visible to Windows Explorer after the failed installation, but inaccessible, then it was removed altogether during the reboot process. I know that there is some way Windows deals with marking files that are in use for removal or replacement during a reboot (as in Windows updates or other installers that will sometimes notify you a reboot is necessary, or some installers which give you a choice between attempting to close everything that's in use or requiring a reboot at the end), and maybe that's being invoked here somehow. If so, that suggests there is a deletion attempt being made on this folder while it is considered by Windows to be "in use". Which to me further suggests that either 1) One process from within the installer/uninstaller is doing something in that folder and isn't letting go of it before the step comes to delete the folder; or 2) Publisher, once launched, leaves something running or otherwise holding onto its program folder long after it has exited, making the installer unable to remove that folder. The second theory comes to mind because I think most (all?) times I've run a new installer, it has been in the same powered-on-and-logged-in session in which I earlier had Publisher running.
  3. Still having install-over-previous-version failures. I tried then running the old version just to see if it at least got as far as uninstalling, and the old version can no longer be run, but in a weird way- it doesn't say the item referred to by the shortcut no longer exists; it says it cannot be accessed, ("you may not have the appropriate permissions"). So I went to the file explorer and browsed my way to Program Files\Affinity\Publisher Public Beta and found that I can't open that folder. ("Access is denied.") I can't see who the owner is, even, or browse into it using admin priviliges, or take ownership of it. The folder is in a weird, inaccessible state, and I don't know what user it belongs to. Going to try rebooting and seeing if I can read it then.
  4. Thanks for the updates. Still unable to install directly over the previous version on a single try without rebooting, though. Windows 10 (1803), updating Publisher from beta .162. Logs are attached for three installation attempts. You'll note that the failures seem to be permission-related...but the failure and success both happen while logged in as the same user, with the same UAC popup approval given. So my best guess is that there's some issue with a lock on the folder involved (or a file in it) that's still active at the point that the uninstaller or installer is trying to delete or modify the item in question. Attempt 1: After running Publisher to check whether I had the latest version, exited, downloaded the newest, and ran the installer. Installation failed. Attempt 2: Tried again immediately. Installation failed. Attempt 3: Rebooted, logged back in as the same user. Ran the same installer. Installed successfully, and launches successfully. Publisher .167 install logs.zip
  5. trajanmcgill

    Double sided printing

    1.7.0.162 does not have that problem for me, at least not on my initial test with a single printer and a single, two-page, letter-sized document. Several releases ago, there were some problems with it doing the opposite of what I selected there, though. Are you running build 162? If so, can you give instructions on how you can reproduce this from a new document? I do see what is probably a bug related to this, though: the print dialog does not remember your double-sided selection. Most applications, if you print the same thing twice without ever closing the application, the second time will have the settings pre-filled identically to what you selected the last time you printed. For instance, if I print a document in Word with two-sided printing selected, then make a quick edit and hit Ctrl-P to print again, two-sided printing will still be selected. Right now in Affinity Publisher, I have to explicitly re-select double-sided printing each time.
  6. Not meant as a nag, just a data point (I'm not sure if anyone has even attempted to solve this issue yet or if it is still just waiting on the list behind other, higher priority things): installing over the previous version still fails, requiring a reboot followed by a second installation attempt.
  7. Thanks. Again, though, unable to do an upgrade installation in place over an existing .145 installation. The key line from the log file appears to be this one: +Error: The installer has insufficient privileges to access this directory: C:\Program Files\Affinity\Publisher Public Beta. The installation cannot continue. Log on as administrator or contact your system administrator. That's a surprising line, because when running the installer, it does do a UAC admin privileges request. So somehow those privileges are not being passed on to a sub-process...or something else is going on that is preventing access (e.g., one process kicked off by the installer has files open in that folder and therefore they can't be deleted or changed by another). Setup.log SetupUI.log
  8. trajanmcgill

    Beta 1.7.0.145 (Windows)

    Yes, this seems to be a consistent issue for lots of people, including me. Hopefully they'll address it before a finished release version shows up, but installer stuff I'm guessing is behind a lot of other things on the priority list. The way I've been upgrading each time is to uninstall (or attempt to install the new version and let it fail), then reboot, then install the new version, and the installation seems to work after that reboot. Upgrading smoothly just by running the installer with the old version still installed has never once worked for me on either of the two PCs I've been using, and I've installed every beta version that has been released.
  9. Using beta 1.7.0.128. There may be other paths to reproduce this, but here's the one I found. 1) Create a new document. Mine was a letter-sized, portrait-oriented document. 2) Click the "Add Page" button. When the dialog comes up, specify adding 4 pages after page 1. 3) Choose Page 1 in the page navigation list on the left. 4) Click the image insertion tool. Choose an image. Click on the page itself to insert it. 5) Unexpected behavior: The image is inserted onto page 2, not page one. At this point, clicking any of the pages in the page list on the left will change which page is highlighted, but will not change which page is actually shown. The page with your newly inserted image will remain displayed, and will remain the active page for any other things you add. 6) Further messing around...if you right-click on any page on the left and choose to delete it, the currently displayed page will finally change, to whatever page followed the deleted page. But then that page remains stuck as the one you're working with, and the same problem persists (inability to change the active page by clicking on different pages on the left).
  10. trajanmcgill

    Page navigation not working

    Okay...but then what's the point of the blue highlighting square that goes around the page you select with a single-click? That is a pretty strong visual indicator of which page is the current one. There does appear, looking closely, to be a much less visible gray square which appears most of the time around the actually displayed page, but I never even noticed that before now because the blue selector is so much more apparent and looks like something that would tell me which page I'm looking at.
  11. Simple, 2-page document, letter-sized. Double-sided printing options are working backwards-- flip short side actually flips on the long edge, and flip long side actually flips on the short edge. I have seen a print driver that under certain circumstances gets this backwards, but in this case, I'm using a printer and driver that I print to many times a day in exactly this fashion, and other applications work correctly with the same printer and driver. Otherwise enjoying so far.
  12. I had the same problem as above (install from build 58 failed, and left no usable installation), and the suggestion above (rebooting and allowing pending Windows updates to complete) did allow me to install. I do think it is a problem that there is no uninstaller.
  13. trajanmcgill

    Double-Sided Printing Incorrectly Oriented

    Build 128 appears, at least for the simple case I saw, to have corrected the problem. The release notes don't have it quite correct (it was not always flipping on the long side; it was actually doing exactly the reverse of whatever was selected), but both flip on short and flip on long side are behaving properly for me now. Thanks.
  14. trajanmcgill

    Double-Sided Printing Incorrectly Oriented

    Would be happy to...but how do I identify build number or find the latest? I'm running 1.7.0.58, with a digital signature date of September 5. The installer I used is bit-for-bit identical to the downloader currently offered to me for download on the "Your Affinity Downloads & Product Keys" page. Is there another place to download a later build?
  15. I love the interface and what it looks like I can do with this software. However...it's severely crippled for me right now in how useful it can be to me, because it can't seem to deal quite properly with the raw (ORF) files from my Olympus E-PL2. Here's what I'm seeing upon importing one of my files into Affinity Photo. 1) The pixel dimensions are wrong. Camera manual tells me that in the mode I'm in, I'm shooting 4032 x 3024 images. Adobe Camera Raw agrees. Affinity Photo, however, thinks the image is 4096 x 3084. There is clearly extra material in the photo as compared to what the in-camera JPG and Camera Raw are giving me. 2) Most or all of my raw images have, at least when zoomed to certain levels, a thin solid line displayed along the left side. I don't think this is making it into the image itself, but not sure...it might just be a UI display artifact of some kind. 3) I was sure I had seen on a few shots a clear issue of bowed lines, although I can no longer find the images where that was clearly visible, and am not sure which lens I was using for those shots. I don't know what could be accounting for this, but I'd sure like to start being able to make use of this for developing raw images. The fact that it isn't even producing a file of the right dimensions makes me unsure how much to trust anything else that's going on in interpretation of the ORF file. Forum doesn't seem to want to let me attach an ORF file, but I guess I can find a way to provide a sample file if needed.
  16. trajanmcgill

    ORF (Olympus) raw file strangeness

    Oh, and I forgot to mention: the vertical line I was talking about appears when opening this raw file in Affinity Photo and zooming to 36%. For other photos, I can see it at the fit-to-window size.
  17. trajanmcgill

    ORF (Olympus) raw file strangeness

    Ok, thanks. Attached is a ZIP file containing the output from my camera. I shot RAW+JPG, so you can see both the camera-generated JPG and the ORF file. I'm seeing the following: 1. The camera-generated JPG measures 4032 x 3024. 2. Adobe Camera Raw CS5 treats the raw file as representing a 4032 x 3024 image. whereas: 3. RawTherapee 4.2.1 treats it as 4088 x 3076. 4. Affinity Photo treats the raw file as a 4096 x 3084 image. My guess would be that there is some kind of data embedded in the raw file that indicates either what part of the sensor data to use, or lens correction info, or perhaps data about how the in-camera jpg was created, that Affinity Photo (and RawTherapee) is not reading or handling the same way (although the latter two differ even from each other, and I don't know why that would be). Is there a good explanation for this? Or is it a bug, or a lack of proper recognition of the lens being used? If I have to do a slight crop on every single image just to get down to what I saw when composing the shot this is going to be a potentially burdensome raw processor. It's not a ton of extra data, but it's enough to leave in something I was trying to keep just out of the edge of the shot, and it isn't even the same aspect ratio. Thanks for your assistance. Camera Output.zip
×