Chris_06
-
Posts
37 -
Joined
-
Last visited
Everything posted by Chris_06
-
Text is tiny at the top of next frame when frames are linked
Chris_06 replied to tcdaly's topic in V2 Bugs found on Windows
FWIW, this bug manifests in a variety of circumstances. Most likely it is because each of those paths passes through the section of code which is buggy. Thus it will not matter what the source or what the specific user-procedure, the bug will manifest if that portion of code is traversed. The nice thing about having different paths which intersect the buggy code is that it should be pretty trivial to locate. -
I'll be working on a publication in the next few weeks where the issue appears. I'll probably open a different thread and post some pics there.
-
There is a real issue with the entire text wrap in that it does not reliably play well with the text flowing around the object. Its a bit complicated to describe which is why I've not taken time to open a bug report on it. And it is possible to mung around with things until the optics are acceptable. Text wrap and flow are complicated interactions to handle programmatically I'm sure.
-
I was able to duplicate this and concur with the suggestion that the default distance should be 0mm and the edges locked on as in other places.
-
Which further supports my conjecture that an underlying code change introduced a regression in the "default" anchor point coordinates. That or the original behavior was a bug in and of itself. Either way, it sounds like a straightforward fix. Thanks @Dan C
- 12 replies
-
- 1
-
-
- 2.4.0.2301
- datamerge
- (and 4 more)
-
Text is tiny at the top of next frame when frames are linked
Chris_06 replied to tcdaly's topic in V2 Bugs found on Windows
This is good news.- 23 replies
-
- 1
-
-
- afp v2.1.1
- windows 11
- (and 1 more)
-
For further clarification, in the example attached to the OP, the properties of the seal image are set to "Scale to Minimum Fit."
-
The x,y position of the image should be stored as part of that picture frame object and should apply to every instance of that frame generated by the merge table tool and then applied to every image linked to that picture frame instance. Somewhere in the code that is not happening. I would suspect that there is a hard-coded default position when a picture frame object is created and that it is never properly updated. But that's just arm-chair code debugging. 😁
-
Okay. I just took a better look here and see what you are suggesting. First: The image does "move" after incrementing the record. That in itself is a bug. This same layout works fine in previous versions of AP. Second: One should not be limited to Max/Min fit scaling. Previous versions of AP did not have this limitation. The only way to "discover" the "location" of the seal after incrementing is to zoom out wide and look for the box when clicking the position tool in the picture frame. If one is not zoomed out and has no idea what has happened, locating the image is practically impossible. This only reinforces the fact that this is a bug. Thanks again @Old Bruce
-
In the production document I need no scaling on the seal. The merge results are fine in both production and the demo on my installation. Thanks for the suggestion @Old Bruce
-
The attached sample manifests the bug as it occurs on my install. Open the AP file. Open the Data Merge Manager Check 'Preview with record.' Note that the seal (a jar of Claussen pickles) is visible. Increment through the records. Note that the seal disappears and never reappears. Generate the merge. Note that the seal does appear in the resulting AP file. Close the generated file. In the original file Data Merge Manager, remove the CSV. Add the CSV back in. Check 'Preview with record.' Note that the seal is again visible. Rinse and repeat to see the bug again. Let me know if something is missing from the zip. Thanks @Dan C. merge_image_bug_demo.zip
-
AP 2.4.0.2301 Win 10 Pro 22H2 Build 19045.4046 This bug was not present in AP 2.3.x. Picture frames placed inside a data merge layout and linked to a field in a CSV file which contains a path to an image show the image when initially placed and linked. However, incrementing through the records in the file in the Data Merge Manager window causes the image to disappear completely. Reloading the CSV file does not correct the condition. Closing the AP document and reopening it does not correct the condition. Opening prior AP documents which worked fine in previous versions results in the same behaviour in 2.4.0. Oddly enough, when the merge is generated, the resulting file does contain the image. So the bug appears only to affect the layout view. Of course, this bug makes layout and editing complicated.
-
Pages inserted by the Book feature are always blank in my experience even though I remove all blank masters from all chapters. I suspect that the underlying code might indeed be using a master, but it is using a default of some sort rather than one based on the current document/book/etc. As you point out: This should all have been fleshed out by the design folks or at least should have been scared out during Beta. The current solution actually appears to have been designed to address a very specific layout. But I'm second guessing here.
-
Assumptions based on spreads: 1. The Book feature attempts to start all chapters on the right-hand side of a spread. (This really should be a user-option.) 2. Merging attempts two things: a) remove unnecessary blank pages in an effort to accomplish #1; and, b) maintain proper alignment of spine oriented margins. 3. Padding attempts to add blank pages in an effort to accomplish #1. If those assumptions are correct, then merging should probably happen first, and padding cleans things up. Note to the development team: Publishing the current design logic flow of this would probably go a long way towards a) clarifying intent and present functionality; and, b) helping solicit more useful feedback. Right now this exercise is like attempting to sort rocks from a kilo out using a rubber toothpick... 🙂
-
This is what I observe. That seems to be a very real possibility. It does not appear to merge at all that I can tell which makes me wonder if the order is incorrect resulting in merges being "overwritten" by padding.
-
See my comment on this thread. FWIW, I have posted my thinking in more detail in that thread.
-
I find this to be true as well. Furthermore, I find that pad behaves in an almost random fashion: Sometimes it adds one page (front OR back) sometimes it adds two (front AND back) where in either case the opposite was correct. At the moment, I don't see the added value of the Book feature over the Section feature.
-
Move it where you like. I certainly have no control over that. However, I maintain my contention that this is a bug. Even if it is a design bug rather than a coding bug.
-
In that case, I would recommend hiring some folks from the publishing industry to assist Serif in their quest to produce "major league" publishing software. This is not the first time Serif has missed the mark. If inconsistent padding/merging is an expected behaviour (or worse, an intended one), I would call into question the qualifications of whoever is in charge of feature design.
-
This could be accommodated even with the fix I request. One option could be to apply no master. In short: I would expect any pages Affinity "adds" to be as configurable as any page I would add. That should please all of the people most of the time.
-
If I only set for one author I might be able to get away with that. But everyone seems to like it different than the other one. 😵
-
Affinity Publisher 2.3.1 Windows 10 22H2 19045.3930 With pad/merge AP will attempt to add/merge pages to maintain correct left/right page layout between chapters (or at least that's what it appears to do). One would expect that when AP adds a page that the new page would have the first master page from the selected style source chapter applied to it. But this does not happen. To the contrary, a completely blank page is inserted to pad which really just ruins the layout of any particular book rendering the Book feature a non-feature. The tool should at a minimum apply the first master page found in the style source chapter to the new page inserted to accomplish the padding. A better option would be to allow selecting which master page should be applied from the style source chapter. This seems to be a basic oversight on the part of the feature planning department. Its hard to imagine actually being able to use the Book feature in its current state to go directly to a published book. PS. I have read the several threads in the other forums regarding a number of issues with the Book tool. This one fix would seem to address several of the symptoms described in those threads.
- 12 replies
-
- 1
-
-
- affinity publisher
- version 2.3
- (and 5 more)
-
++
-
There is some sort of nasty bug which results in the style being messed up across linked text frames after importing into AP. To make things more maddening, the manifestation of this is inconsistent. Thus far, I have been unable to "fix" it when it happens. So I just gave up.
-
Unfortunately there is still buggy behavior which has little to do with feature crossover. We finally resorted to just rebuilding our publications from the ground up in AP. The time spent was well worth it.
