Row removal changes boarders and paragraph formatting

English
,
#1

Version: 7.6.4.1 (X86_64) / LibreOffice Community
Build ID: 60(Build:1)
CPU threads: 2; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
7.6.4-1
Calc: threaded

Crazy Writer drives me crazy.
It doesn’t suffice to commit for consequent style-based writing.
It doesn’t suffice to commit for consequent template usage.
Few further commitments don’t suffice.
It doesn’t suffice to get familiarized with rules of game.
It doesn’t suffice to meticulously take care every step.
Working with Writer is still hurdles run.
Tons of exceptions.
Features which I consider to be supporting me on my productivity are recommended to avoid as of my expertise level.
I miss the day I wont need Writer any longer.

Removal of table raw results not only in removal of such. Cell boarder get also yet miraculously changed, paragraph formatting get modified. Table was put to document from autotext.
Template to child inheritance still not working, neither for child documents created last sixty minutes.

#2

What is your question?

Maybe a sample or procedure steps from beginning to non-achieved goal

#3

Document created from custom template. So far two pages on document creation achieved: couple of Headings, couple of placeholder blank paragraphs, up to 3 body text paragraphs. At the end a table inserted in document. Document still very distant from be complete - that means further editing takes place right now, new contents are added to document as for few coming days.
Row removal leads to effects as in OP.

#4

Attach this file for analysis. And, please, try to improve your English practice or post in the leg corresponding to your native language if it exists. Posting on this international leg requires translation from your language to “conventional” international “Globish” then translation again from there to contributor’s local language, both steps implying approximations. If you can’t by yourself, get help from a friend.

#5

I try to keep my statements short because the longer the sentence the higher the risk to fall in unclear/ambiguous expression.

That’s amazing what Writer is doing in my table.
One more issue in this regard.
Table was inserted using custom autotext (according to one recommendation received few weeks ago). Subsequently table was filled with content, in next step few formatting changes were applied inside table and on it (paragraphs, and table borders). Subsequently I like to add one row, Writer carries out reset of all applied formatting modification inside table when I insert one new row.

#6

This sounds like you have use so-called table styles (which are no styles at all but rather a collection of macros). Whenever “critical” factors in the table are modified, e.g. adding/deleting one row, the macros fire again and reapply their formatting, erasing yours.

To make sure, attach your sample file.

Presently, table styles are not reliable. You have to accept them “as is”. If you add/modify formatting in the cells, this user formatting disappears as soon as the macro retrigger to maintain their “invariants”. IMHO, the feature is ill-designed. I prefer to work with “no style” tables so that I can apply my own formatting.

#7

Document and its template may have table styles defined because it was my first approach in the past. But that style is no more used. As mentioned previously table was inserted in document by using custom Autotext according to one recommendation got here in the past but in the close past. Some day in past but no so far I was informed here in forum rather to refrain from table style usage, and the recommendation was given to switch to table in autotext which myself followed immediately. I follow that recommendation till this minute.

Thanks to your kind hint I checked this table style autotext last minute and couldn’t see the table to be using any other table style than the default one.

#8

If you made your AutoText from a table initially given a “table style”, this “table style” was kept in the AutoText.

Once again, attach your file for thorough analysis.

EDIT: sorry for the typos in the first version of this comment.

#9

Can one utilize the mechanism as above to modify table style then let the modification to get distributed to all tables based on that style (see one discussion in the past, link below)?

P.S. My document in your ask.libreoffice message inbox.

#10

Are things constructed that way one won’t be able to see it in autotext open for edition?

cit.: If you made your AutoText from a table initially given a “table style”, this “table style” was kept in the AutoText.

#11

Implementation of table “styles” is absolutely awful. It is next to impossible to see afterwards if a table style was used or not. The only way I know is to save .fodt, then scan the XML to see if tables have an attribute table:template-name.

After analysing the document which was privately sent, I confirm all tables are styled Default Table Style which is not the same as None style. None has no style attached. Default Table Style is a badly chosen name because there is effectively a style attached to it. All your problems come from this.

LO is becoming victim of featurism where “features” are added, mostly to respond to users familiar with M$ Word wanting to find the same workflow as under M$ Word but not realising that Writer is built on different principles (and IMHO more regular, strictly specified and in the end more powerful). Switching to another tool requires the courage to forget everything you think you know about document processing and to accept to re-learn everything, starting by reading existing documentation.

Before requesting features, requestors should try and figure out if their goal can be achieved within the existing version of Writer. This would avoid many harmful side-effects.

#12

Thanks for your check and information.
Any chance for my table autotext to get default table style removed from table - it means back to table style None?
Same questions applies to tables created using this autotext.

Conclusion for me from your last answer: it will be reasonable to undertake no trials of go-back to table style usage (apropos Row removal changes boarders and paragraph formatting - #9 by eighty2)

#13

The safe approach is to delete the existing AutoText and to replace it with a new one based on a fresh new table without any style.

Regarding existing tables, if you’re not feeble of heart:

  1. save your document as .fodt
  2. open the .fodt in a text editor (gedit, geany, kwrite, …)
  3. replace all occurrences of “ table:template-name="Default Style"” (note the space at beginning of string) by nothing
  4. save
  5. open the .fodt in Writer to check everything is OK
  6. if everything is OK, and only in this case, save as .odt or replace your existing document
    It is probably better to increment the “revision number” in the filename to be able to roll back in case of problems.
#14

Anyhow, regarding the amalgamations you’re pointing out (of table styles) isn’t it a chance for user to use following functionality? Conduct modifications of table style in table style, subsequently let those modifications get distributed to all derived yet existing tables in document - apropos Row removal changes boarders and paragraph formatting - #9 by eighty2.

#15

Unfortunately, no. Because table “styles” are not styles like paragraph or character styles. They are a collection of macros attached to individual tables. There is no way to centrally customise tables.

I complain about these so-called “styles” because they are really traps for users. If you need table customisation, keep away (and with a far safety distance) from them.

#16

Thanks. I consider to go the .fodt-based trail. After carrying out the procedure will I be able to still use my table autotext in order to insert more tables to document?

#17

Yes, but your AutoText will still be plagued with table styles. The really safe trail is to re-create your AutoTrail once you have removed styles from the tables. You can select one of these as the “model” for AutoText since you’ve got rid of the table style.

#18

This concludes also in following: In Insert Table dialog never select predefined table style, select always None.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.