Franz Rogar

And...? Just because you posted in a public thread I must remain silent? Of course, I'd NEVER EVER do a "No capitalization but the first letter", because that would be a TERRIBLE approach. Example: "La caída de la casa de Usher" is a proper Spanish title, whereas using "No caps but first" would transform it into a monstrous "La caída de la casa de usher". Again, as I pointed, "Titles" is a broken piece of code that remains only useful in English (after editing the "ignore this, this, and that, and that..." list). As I've voiced in many other issues, the root of all this is APub wiping the character formatting and forcing a wrong vanilla one that forces you to overwork something that already works in many other DTPs (even word processors).

That's where I differ. I do expect the name of an object to NOT change at all in any part of the GUI. If any further information is required, that should be on a floating text (alt) instead. That way, I'd have found directly that the style associated with "split notes" is "split notes", not "continued note". But that's my honest opinion, as someone who have fought against many UI faults along the years.

That's an useless setting for two reasons: It's placement is out of reason (why would I go to the app "Settings" for a style-related issue?). It should be included into the "Fields" tab or somewhere sane. What should I type into that useless field when ALL words (but the first one) are NOT capitalized in Spanish titles? Should I write the whole dictionary in it? Ain't more obvious to DO NOTHING and USE what the user wrote in the first place? This is also applicable to the TOC and its character formatting wiping... terrible approach, totally counterproductive.

@Chris B I've updated the NVIDIA drivers and, so far, the issue seems to have disappeared. The offending version (where it happened always) was 572.42. So I'd point to be a problem with the drivers... I can confidently discard the integrated Intel 'cause it has not updated the drivers at all. Or maybe it's a niffy problem with the forced Windows 11 system (Settings > System > Screen > Graphics) to run the apps with one or another graphic card (instead of the dedicated NVIDIA app it was done before)...

I'm just clicking (left-click). No right-click involved.

NAMING ISSUE In "Notes > Positioning", there's an option called "Allow split notes". In "Notes > Rules", there's a drop-down menu for "Rule before" with two options: "First Note" and "Continued Note". "Split notes" is the "Continued Note". SUGGESTION Rename "Continued Note" as "Split Note".

FOUND IT: under "Notes > Rules", the "Rule before" drop-down menu has "Continued Note" which is referred as "split notes" in "Notes > Positioning". They have to be named the same if they represent the same object. So, please, fix the UI naming. Is there any way to edit the (extremely) thick line added when ticking "Allow split notes"? It's too much of visual impact in the design I'm working with. Thanks in advance, Franz.

So that's what they meant with "Overflow"!? I looked for the manual page for that after you pointing it out, and the real description of what the modifiers to is in the *last* sentence: "Text frames, of same dimensions and properties, are created on multiple new pages until text overflow no longer occurs." Thank you very much! Then, it's already implemented but TERRIBLY named and the manual page should move "what the tool does" to the very beginning of it... instead of being the last sentence.

I've re-read your comment and this reply but I still don't understand what you're trying to convey. (English ain't my mother tongue, so it's probably a "Lost in Translation" issue). In the example I wrote about, a novel of 1,000 pages: a) How can't you find the "next-page" linking option not also part of the "mostly" even being a "single stream"? b) The text *will* overflow of 1,000 pages... So, instead of taking advantage of a "master" page that automatically creates 2 linked text-frames (spread), are you proposing that I have to manually create, adjust, position, link them + then "shift-click" from previous page... 1,000 times? I don't understand it.

Why would I copy&paste? That's a recipe for disaster... If your publisher decides to change the page size... or you decide to adapt from big hardback to smaller paperback... then you'd have to select one-by-one, thousand of text-frames, and resize them, repositioned them, one-by-one... Also, adding this support, would be helpful for some classical texts presentations too (for example: polyglot texts), as you pointed out.

WHAT IS REQUESTED Support for linking "next-page" text-frame in a master-page. WHY IS THIS USEFUL? For example, editing a novel 1,000 pages long, in a spread master with a single text-frame in each page. You link the first page text-frame to the second page in the master. Now, if you had this "next-page" link option, you could link the 2nd page frame to the 1st one, so each new page you add, it will auto-link the 2nd text-frame of previous one to the 1st text-frame of the new one. But, because this feature doesn't exist... you have to click 3,000 times (one to select the text-frame, one to click on the triangle, one to click the next-page text-frame) and scroll (with luck) 1,000 times too. ALREADY IMPLEMENTED It's the "Overflow" option that appears when click Shift+(click on Text Flow button:aka:crossed-red-eye). The manual page for it it's not very clear about it and it's in the last sentence that it clearly specifies that it "creates NEW pages, with the linked frames between them, automatically.

Thank you very much for the "easier" and cleaner way, but that suffers from a side issue: if you change the font size, the hanging is no longer "visually proportional", forcing you to manually resize the indents. Thanks why I used "em spaces" for that, so all rules hang the same width (which your workaround does) and keeps been visually pleasant (which will be lost as you change the font size farther from the original one, forcing you to manually tweak). It'd be nice if the "indent" field would allow for "em/en/thin/..." spaces as measurement unit, not just the document one (in this case, mm). As a real example, Inkscape "number" fields (everywhere they are) take the "document" unit by default (for example, "mm") so if you write: "32" it recognizes "32 mm". But if you write "32 px", the object is resized to "32 px", not "32 mm"; if you write "32 pt"... et cetera. Inkscape "converts" the unit (as far as I know) to the "document" one (to avoid bugs with future calculations) automatically, but in this case it'd be great if they were "kept" (em/en...) instead of "converting" them to the document one (mm).

Thank you very much for the workaround, and I agree with you that the "English title" rules (because they are VERY different from the Spanish title rules, which is the language the text is set, and that should be taken into account IMHO by the "Title") should be set to none "by default".

I concur this is a really annoying issue that I've just been truck with. And even more, it's just painful to work with just like with the TOC because APub keeps blatantly ignoring the character formatting thus rendering the <Running Header> just useless and the program counter productive (forcing you to create specific "master pages" for each header just to have a proper formatting. Edit: the inline text heading looks weird because the text body is a two-column one, so it's "properly" centered into its column. But this just have thrown a bug with the <Running Header>: the heading in-body text uses "Typography > All Caps" but the <Running Header> uses "Typography > Small Caps"; and the "y" in the title is writen in lowercase... so it should be shown as "small cap" not as "capital" in the <Running Header>... I really hate APub for not keeping the character formatting in TOC/fields... EDIT 2: I've just realized that it capitalizes everything in the English way... "S... I... Y D..." instead of the proper Spanish one "S... i... y d..." How I hate this systematic infection of clearing the character formatting and replaying with a vanilla English one...

ISSUE I want to create an underlying rule that it's 2 em spaces wider (left and right) of a field text. The issue is that the ending em spaces do NOT get the underlying rule. WHY I CONSIDER THIS A BUG? Even though "ignoring" spaces at the end of a sentence might be thought of being useful to the lazy editor, I don't think they should be ignored because they are, after all, part of the text. WORKAROUND As "workaround", I've added a "transparent" character at the end with a tracking of "-500%" (thus reducing its horizontal space to none). It'd be a nice to add "horizontal rule" support to APub, via "Paragraph > Decorations" + "length modifiers".