adrm

If you set a table as Inline In Text and add or subtract rows to it, it will not: respect the following text when rows are added. I.e it will overlap the following text the table placement shifts up, even beyond the text frame it's inside, when rows are subtracted. At least when the table is at the top of a page - I haven't bothered to check if it happens if the table's vertical position elsewhere on a physical page. If you toggle the table to Pinned, then back to Floating With Text, then back to Inline, the program catches up. If you just toggle Inline In Text off, then on, other weirdness ensues. Try it. This bug aside: Please Serif, do give some priority to improving tables. The whole implementation (inserting, page breaking, editing, pasting, etc) feels clunky to the point where I don't feel like using Apub for documents relying on tables. MS Word is currently a better solution is these cases, in my opinion.

I did some further testing. As has been suggested elsewhere, the issue seems to be with Word tables that span more than a single page. With a large Word document, these can be hard to spot, not to mention know what to do with. Breaking them up inside Word seems like it's a huge amount of work and seems very prone to break when text is added or removed from the (Word) document. Any suggestions on how to work around this? The document I'm looking at right now has hundreds of tables.

I just ran into this myself, using v2.1.1 When I tried importing (Placing) the document in .DOCX format, text appeared up until the point where the first table should be, then it just kept adding blank pages for every shift-click on the auto-flow arrow. Even beyond the number of pages in the original document. When I saved the file as .RTF, I got nothing but the blue, spinning circle. I had to terminate APub using task manager.

Ah yes, that was it, I believe. I can't verify the details against what you write anymore, but it sounds about right. Thank you. Now, why do the placed images end up where they did, I wonder? I tried to control where they were placed, e.g. by placing the cursor inside the text I was working on, or making sure the correct layer in the stack was highlighted. But no matter what I tried, the images seemed to end up in random/unexpected locations on the stack. Most of the time, they ended up at the top of the stack, but sometimes in other locations.

(I vaguely recall discussing a similar issue on the version 1 forums, but I can't find it when I do a search now. If this has been addressed before and I'm just being dim, my apologies) Background: A brand new document created in APub v2. Mostly 2 column spreads (based on a master), with a few odd pages for images and such (also based on masters). Issue: When I use the Place Image tool to insert an image inline with the text in a column, the image sometimes appears in the text column as expected. At other times, e.g. just after placing the first image, images end up in other places on the layer stack. Whenever this happens, the image can not be moved inside the layers panel, nor deleted. The only way to resolve this is to use Undo back to the point before placing. I am not at the PC that has APub installed (curse you, new licensing model), but I believe it works as expected if I have selected Inline in the appropriate settings panel BEFORE placing the images. If it's set to Pinned, the images tend to get "stuck". If I'm doing something wrong when placing the images, it should still be possible to delete them afterwards, right? (I do not have an example document to upload, as I had to abandon the version 2 one, because of multiple issues such as text disappearing when reopening the document. APub v1 is still the way to go )

This happens on the first right-click. If the click is repeated a second time, the menu appears at the expected location, i.e. beneath the layer entry in question.

I suspect It's a (very) rare issue, but I'll post if it happens again.

Yesterday, while experimenting with object pinning parameters, I experienced something that appeared similar, if not identical, to what others have reported in the past, i.e. pre-v1.10. Including on the Mac version. At one point, the backspace key no longer worked as expected. Instead, a hollow square, similar to the one that is displayed if your font does not support a particular character/glyph, would appear. Additionally, pressing the Delete key (with the cursor inside the text) would result in the entire current text frame disappear. (I believe, although I'm not 100% sure about this, that all other linked text frames on other pages also disappeared) As with the other reports of similar issues, mine fixed itself by restarting APub and reloading the saved document. Just a heads up to the devs that an old problem is still present in the code somewhere, although it seems rare and hard to reproduce.

Clearly my understanding was less than perfect. Thank you.

I'm reasonably familiar with master pages, and I can't see how the master page causes what I'm seeing. My issue is with objects (tables and images) inserted on regular document pages.

Sorry, but I fail to see what you're saying.

In the latest version (1.10.4.1198) I'm seeing this consistently, as demonstrated in the attached file. Steps: Create a new document Set up a simple master with text frames. Add some text Add a table Try to move the table into the (non-master!) text frame The table is now stuck / locked and can not be manipulated in any way. Is this a bug, or am I just causing this by being inept? Locked table - test.afpub

That's still quite some difference in time used for the process. In my case either 4 seconds or 55 minutes (The latter a 800 times increase) In your case 50-ish seconds. A 10 times increase compared to my lowest time. Anyway, what interesting to me is that the program manages to complete whether I do the Layer->Unlock All, or not. It merely takes 800 times longer if I don't do it. I'm thinking this should be of interest to the devs.

I have an update on this. Today I tested with the latest official release: 1.10.3.1191. I opened my afpub-test file. This time around I noticed the warning "The section is locked and cannot be moved". I have no idea what exactly is locked and how this came to be. It's basically a new document with a ascii text file placed in it. However, I did try to remove the lock by doing Layer->Unlock All a couple of times. The warning still remained. However, when I now did a shift-click to auto flow the remaining 1800+ pages, they appeared about 4 seconds later. Clearly, there is a link here, although I have no clue what is going on. I hope this helps? (I'm including the test file once more.) Hang_text1.afpub

Ok, here's what I did now: Loaded the document Scrolled down as far as it will go, i.e. to pages 286/287 Started a timer Scrolled up and down until 2 minutes had passed. Still not getting further down. Clicked the text frame on page 287. No change. Double-clicked inside the frame, i.e. the edit cursor was activated inside a paragraph. Now I could scroll to the end of the document. I'd still call this an issue, as it doesn't seem to be a matter of waiting for the program to "catch up"(?)