Garytagreg
-
Posts
91 -
Joined
-
Last visited
Posts posted by Garytagreg
-
-
Hi,
I've run into a reproducable crash in the current app store version (1.8.4) of Publisher that's been quite a pain for me. I'm not able to install the current beta at the moment so I can't confirm if it crashes there as well, but I suspect it would, too.
Basically, every time I create a document with a certain template I made, the app will crash if I:
- creat artistic text
- use the "Layer->Convert to Text Path" menu option on a curveIf I don't use the template and just use a built-in preset (Print->A4, for example), the app does not crash and runs just fine, so I suspect there is something in the template configuration that is causing havoc somewhere.
An important detail about my computer configuration: I have Japanese installed as my secondary system language (primary being “English (South Africa)”. The template in question does have some Japanese text in it, using "Hiragino Maru Gothic Pro" font, which comes pre-installed with macOS. I mention this as issues with Japanese text have been part of previous issues I've reported here.
I'm attaching the following files that I expect will be useful
- TextCrash.aftemplate : the template in question
- Text on Path Crash Report.txt : crash report generated when I tried to "Convert to Text Path"
- Artistic Text Crash Report : crash report generated when I tried to create artistic textI hope this helps!
TextCrash.aftemplate Artistic Text Crash Report.txt Text on Path Crash Report.txt
-
2 hours ago, Pauls said:
We've just recreated this - looks like something to do with the keyboard input setting
Glad to hear that its getting tracked down
Here is what "locale" gives me
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
7 hours ago, BobFossil said:OP, for a workaround, try selecting the text frame with the "Frame Text Tool" and then using FILE> PLACE to place the file of text. It should go in okay.
My workaround is just to make really big frames before pasting the text, just to ensure it fits.
-
8 hours ago, thomaso said:
• Does it crash for you only when copying from Notes.app, – or from any text editor app ?
No, it doesn't seem to matter where the text was copied from or what app (I just tested it with plain text from TextEdit and it crashed just the same so it doesn't seem to be a rich text issue)
• Does it crash for you if you paste not into an existing frame but simply on a page (and let the frame automatically get created) ?No. That works as expected, even if the amount of text is "larger" than the automatically created frame.
• Does it not crash if you drag the text frame larger before paste (because you mention < enough text to not "fit" in the frame >) ?No. If I make a sufficiently large frame beforehand, it doesn't crash.
• Does it crash for you only with this specific .afpub (because you delivered it) ?No, I just made and attached that file as an simple example without any extra content that crashes every time for me.
Thanks for the replies, I've answered the questions above and I've attached the crash report.
I had some really wierd crashes with early versions of designer that eventually were found to be due to having Japanese installed as a secondary language on my computer (I live in Japan but I'm not Japanese). I seem to remember that it was crashing a menu somehow, even though I was doing something apparently unrelated. I'm just mentioning this again as it is the main difference in my setup to most folks.
Hope it helps.
-
I'm getting a reproducible crash on publisher with the following steps:
- create a new document
- create an empty frame text frame
- copy a block of text several lines long from another app (I've been using the Notes app) that has enough text to not "fit" in the frame
- crashes every time
I've attached a sample file with the empty text frame and a file with some random text. if you paste the text from the text file into the frame in the publisher file it crashes immediately.
It also crashes the latest beta at this time (1.7.3 475).
I'm running Mojave 10.14.6 on a MacBook Pro (Retina, 15-inch, Early 2013). As I've had weird crashes connected with text in designer and photo before, I should also mention that macOS has Japanese as a secondary language installed but that the text being pasted does not have any Japanese text in it.
Hope this helps
-
All right then...
I just control- started the app and cleared all data and now it magically works... :rolleyes: There must have been something cached somewhere that was affecting things.
So its all good now, but a pity we couldn't nail down exactly what was causing it.
Thanks all! :)
-
I've just tried this on my Mac and the Windows version and everything seems OK :unsure: I think the issue is definitely isolated your end. I get a minor redraw lag but only very occasionally. Nothing untoward in my Activity Monitor either...
Oh boy, not another one of those :wacko: ...
I just tried it in the latest App Store version on my El Capitan partition and it worked fine: smooth, no beachballs...
-
I just tried moving stuff around on "Icecream Thing" sample and I get a definite 2~3 second delay when moving its shapes around. Usually not a beachball but I did get one or two in my test.
-
Just tried it on a iMac (2010) with latest Sierra 6 Beta, no beachball. Do you have more programs running? Virusscanner perhaps?
Nothing else major is running, just AD and safari and a couple of menu bar apps. I even reinstalled AD from the App Store.
Did you manage to move a window on the building around? The scene itself works fine and I can pan and zoom around nice and smoothly without any beachball. Its when I try and move a window on the building to another place that it dies. Interestingly, option-dragging a window to duplicate it works fine, but will cause the beachball once I "let it go" and try to move it.
BTW: during the beachball, activity monitor shows 100% CPU utilisation and no noticeable change in memory usage (about 350MB). If it succeeds in completing the move, CPU returns to 2% and the beachball disappears.
-
Hi
I was testing out the symbols by making a simple isometric building with symbols for the windows and, while I managed to make a decent number of them, now trying to edit things by moving the windows around is dramatically slow, with the beachball coming up and usually ending with me having to force quit the program.
Panning and zooming the scene is fine, but just trying to move a window by even a tiny bit brings up the beachball.
While I can understand that there are quite a few shapes, groups etc. in the scene, it doesn't seem to me that there are so many to cause such a dip in performance. Maybe its something to do with symbols backend? Or, am I just being overly ambitious ;)
I've attached the file in question. Try to select and move a window around. Hope it helps :)
My system:
MacBook Pro (Retina, 15-inch, Early 2013), 16GB RAM, using the GeForce GT 650M discrete card. Latest Sierra Public beta (10.12.2 Beta (16C60b))
AD ver 1.5.4 (Mac App Store version - I can't run the latest beta as its version is earlier than my App Store version)
-
I'm getting a reproducible crash when trying to create a focus stack with the images linked below. I first came across it a beta version or two back but its still happening now so its probably unreported by others so far.
They're not the best candidates for a focus stack (I was just playing around with the feature and some macro shots I took in the garden) but they shouldn't completely crash the program ;)
Sorry if the file is a bit big (66MB - they're tiffs) but I wanted to send them as is, in case its an issue with the file format or something.
Hope it helps :)
-
Mentioned already in the designer thread, but I can confirm that the issue I was having with renaming the currently selected layer is fixed
(I assume that was the "Fix for double-clicking the selected row in the Layers Panel causing the incorrect behaviour.")
Thanks!
-
-
I know they're new and a work in progress but macros aren't very useful yet:
If I make a macro for boosting local contrast with the "radius 100% unsharp mask with a lighten blend mode" trick you made in a recent video on Facebook, it doesn't remember the 100% radius (the percentage, it does create an unsharp mask filter) so to use it on another image, I have to run the macro and then manually go to the unsharp mask filter and edit the radius which the macro should really do for me.
Also, the library is very bare bones at the moment: I can create a new category, but I can't actually put anything in it.
-
Hi
An issue that has been bugging (unintentional pun) me for the last few betas has been layer renaming:
- On a file with multiple layers, select one and do some stuff to the shape. E.g. use the move tool to resize the shape
- Now, double click on the current layer name in the layers panel to rename it
- The history will indicate "set description"
- The layer will be momentarily in a editable state but will immediately revert back to its regular state (almost as if it has lost focus)
Very annoying if you're not paying attention and start to type the text for the layer name as it will start running keyboard shortcuts instead as the focus is back on the main window.
If you want to reliably set the layer name, then you have to first select another layer and then double click on the layer you want to rename whereupon it acts as expected. A small but most annoying bug.
Here's a short screen capture of the above.
I'm running the latest Sierra beta (16A304a), if that has anything to do with it.
Hope it helps :)
-
Not a major bug, but probably an easy fix:
If you show the grid, rotate the canvas a bit and then use the menu to reset the rotation, the grid remains in its rotated state. When you move the canvas or zoom it resets and trying to draw shapes will snap to the correct grid (although it doesn't match with the grid you see) but it looks out of place on an otherwise very professional app.
See Attached pic.
Also, I can confirm that the cropping bug I was having with gaussian blurred group children is fixed. Thanks! :)
-
The clipping issue with members of a child group having gaussian blur I was having is still around.
See attached file. The red shape with the blur is not being correctly clipped. Take the blur off and it clips properly. Note: this only seems to occur when its a group - direct children seem to work fine (move the red layer out of the group and it'll work fine.
Looking good so far otherwise :)
-
A bug I've come across:
If a member of a GROUP that's a child of another object / layer has a gaussian blur applied to it, it is no longer properly clipped by the parent layer. If it is just a normal child and not part of the group, it seems to work fine...
See attached file. The green shape with no blurring is being clipped as expected. The red shape is not being properly clipped and is overflowing on the left side. Taking away the blur makes it clip as expected.
Hope that helps.
-
Our discussions here got me thinking and I got a suspicion that has "solved" my problem (at least where AD and AP are concerned).
I run another app, BetterTouchTool which hooks into the accessibility features (you need to give it permission to access accessibility) and lets you create your own gestures, keyboard shortcuts etc. (e.g. I have a 5-finger click set up to toggle fullscreen - very useful). I don't have anything set in it to a three-button touch but I think something its doing is interfering with the correct operation of the dragging notifications being sent to AD and AP.
I closed BetterTouchTool and the sliders started working as expected. Ran it again and the problems immediately returned.
So, problem solved and I'll take it up with the BetterTouchTool folks. :) Hopefully they can fix the issue because its a really useful app (and, apart from this issue, comes highly recommended by me). At least you don't need to worry about it any more :)
-
Matt,
It may be that they have changed something recently because it was working just fine before. I'm not convinced about the continuing a drag theory, though. I tried continuing a drag immediately after raising my fingers while dragging a finder window around but everything was very snappy (definitely not a half second delay) and reacted as expected. To me, the "accessibility" part might be for people that lack the finger strength to push down and drag?
That said, up till now it was a normal trackpad option and not classified as an accessibility one. Also, I don't get this behaviour in any other sliders in other apps or OSX itself. e.g. the Apple colour chooser handles everything just fine. Of course, though, I realise these are native controls so they might be "special"... However, I use LightRoom as my DAM and I have no issues with the non-native sliders there.
-
Hi,
Thanks for all the comments. As noted by psaldari, the 3 finger drag gesture option has been moved to the Accessibility pane now (Accessibility->Mouse & Trackpad->Trackpad Options->Enable Dragging (three finger drag in the drop down list). I, too, am puzzled at the move as its the most natural control method by far of me: combined with tap to click lets you 3-finger drag folders, windows and sliders around without ever having to "click". Indeed, the only time I "click" the touchpad is when I select my user on the logon screen as it uses the default touchpad options there. As lazy as it sounds, the effort spent pushing my finger down and then releasing it seems crude and unnecessary ;)
Anyhow, I think maybe the move to accessibility may be a clue to why I've only recently seen this problem. I created a new user and enabled the 3-finger dragging and tried the beta. It seemed to work for a few tries as the sliders were working as expected but then I once again had the same issue I described with the video with the sliders. Maybe the move to an "accessibility" option has created a requirement for apps to handle dragging slightly differently? e.g. lifting my finger up after a drag might send a different notification to the app, or something in that vein?
Attached are my touchpad and accessibility settings for your reference. If you mirror them, hopefully you'll be able to recreate the issue :) (Please note the four finger swipes for swiping between full-screen apps, mission control and expose that usually are 3-finger ones but that I changed, too, due to my drag setting)
PS: yes, vonBusing, it is indeed a nightmare, especially as it used to work so well. I hope the devs will be able to sort it out. And, yes, I use quicktime to record my screen captures with the "show clicks" option which is what puts the circles up.
edit: sorry, the attached screenshots were massive - I've shrunk them a bit now.
-
Hi,
This beta (and the AP beta) has the same issue I reported for the previous one (1.3.5.3). The details are all the same so I'm just going to quote it again here. It's really annoying, though and makes AD and AP super difficult to use with even the most basic tasks.
The only thing that has changed since is that I'm now using the latest El Capitan beta (15B30a)
Hi,
I've been experiencing some frustrating issues with the UI slider controls for the last few betas:
My System:
- early 2013 MacBook Pro (Retina), 16GB RAM, default display resolution
- Latest El Capitan GM (OSX 10.11.1)
- No mouse connected, just using the trackpad
- Note: Trackpad set to tap-to-click as I don't like clicking the whole trackpad down all the time
The issue:
- When tapping on a slider UI control it will move the little circle to where I clicked as expected.
- When I tap with 3 fingers on the circle and drag it left or right, one of 2 annoying things happen:
1 The circle moves where I want it to go, but when I release my fingers from the trackpad, the circle moves back to where I just moved it from.
2 Unless I'm 100% pixel-perfect on the (tiny) circle, even if it looks like I'm on target, the slider I previously moved will move instead of the one I'm trying to move now. i.e. the previous slider retains focus and the slider's circle click target seems way too small (because of the retina resolution, maybe?
Its not just on the RGB sliders but all of them: all adjustments and dialogs, and I'm having the issue on both AD and AP so I assume its an issue with the UI slider control itself. But, its making even the simplest edits and tweaks to colour and adjustments incredibly frustrating. :( Note that if I plug in my wacom tablet and use its pen then I do not have the same issues. I don't have a mouse to test it, but as I haven't seen any reports of the issue from others on the forums here, I assume that it works okay with a mouse...?
To illustrate the issue better, I made a screen recording that I hope will give you an idea about what I'm describing (1.5MB in size):
https://www.dropbox.com/s/ssq64lx7u8ekkm1/Slider%20UI%20Issue.zip?dl=0
Hope that helps!
-
Just a quick comment about the Japanese localisation:
A common thing to do with languages that don't use roman characters (Japanese, Chinese, Korean, Thai etc.) is to write the language name in that language in the drop-down of available languages in the settings. That way, a completely non-English speaker can go to the settings and click on stuff until he sees something written in his language which makes it easy for him to change the settings to what he can actually read. Try to imagine finding the English language setting if you were running in Japanese/Chinese/Korean and everything was written in that language (which you can actually experience right now by changing AD to Japanese, restarting and going back to the settings where now "English" has changed to "英語"... not too easy)
Google does a good job of this as shown in the attachment.
At the moment, the list box in the settings menu is all in the currently set language. Doing the above would help make things easier to use.
-
Hi,
I've been experiencing some frustrating issues with the UI slider controls for the last few betas:
My System:
- early 2013 MacBook Pro (Retina), 16GB RAM, default display resolution
- Latest El Capitan GM (OSX 10.11.1)
- No mouse connected, just using the trackpad
- Note: Trackpad set to tap-to-click as I don't like clicking the whole trackpad down all the time
The issue:
- When tapping on a slider UI control it will move the little circle to where I clicked as expected.
- When I tap with 3 fingers on the circle and drag it left or right, one of 2 annoying things happen:
1 The circle moves where I want it to go, but when I release my fingers from the trackpad, the circle moves back to where I just moved it from.
2 Unless I'm 100% pixel-perfect on the (tiny) circle, even if it looks like I'm on target, the slider I previously moved will move instead of the one I'm trying to move now. i.e. the previous slider retains focus and the slider's circle click target seems way too small (because of the retina resolution, maybe?
Its not just on the RGB sliders but all of them: all adjustments and dialogs, and I'm having the issue on both AD and AP so I assume its an issue with the UI slider control itself. But, its making even the simplest edits and tweaks to colour and adjustments incredibly frustrating. :( Note that if I plug in my wacom tablet and use its pen then I do not have the same issues. I don't have a mouse to test it, but as I haven't seen any reports of the issue from others on the forums here, I assume that it works okay with a mouse...?
To illustrate the issue better, I made a screen recording that I hope will give you an idea about what I'm describing (1.5MB in size):
https://www.dropbox.com/s/ssq64lx7u8ekkm1/Slider%20UI%20Issue.zip?dl=0
Hope that helps!
-
Thanks, vonBusing.
I can't remember exactly what I was doing at the time, but I think I was in Finder, so that explains it.
In any case, for professionalism's sake, fix the "udpate" typo :)
Crash when using a template (artistic text and text on path)
in V1 Bugs found on macOS
Posted
Thanks, @SPaceBar !
That’s seems to have done the trick. All working now. I hope the devs will find my logs useful in fixing the issue.