Master Document

[Tom_Davies1]

hi
Please find the Italian mailing lists (or whichever language you feel
most comfortable with)
http://it.libreoffice.org/supporto/
I'm not completely clear what the question is this time. Please
restate in Italian.

Ctrl v = normal paste
Ctrl Shift v = paste special

Paste special gives a pop-up with various options such as "unformatted text".

When you paste as unformatted text it is given the same formatting as
the the surrounding text.

I don't know if that helps at all but i hope something there is useful!
Regards from
Tom

[Steve_Edmonds]

Hi, Tom and others.

I am finding this discussion to be intellectually stimulating though I have no idea as to the mechanics involved in developing or using master documents.

What you write about saving time is most likely very true. However I have probably never written a document with more than about a dozen paragraphs and I have no idea where to look for the study materials that you say can be read in ten minutes thus immediately saving twenty minutes to an hour.

Having shouted the glories of styles, let me also say that their benefit comes from doing the same types of documents over and over again. If I were using Writer to create a wide variety of (relatively short) documents, then styles might make me go mad. To use them properly would require me to create dozens of templates and styles covering every type of possible situation. That might take far more time than just typing the dang letter and hitting <ctrl-p>.

Hi. Even in relatively short documents styles are useful, especially where presentation is involved. In an earlier message the statement "why would you use styles to simply italic a few words" could be answered. I might want to change the weight, font, etc. of all italics through my document later to balance the look. Use of styles makes it easy to tweak the document to get the look you want and to me most logical for anyone with a real interest in presentation.

[Steve_Edmonds]

I sometimes would like a shortcut for pasting unformatted text, without the popup, or for the right click menu to have paste unformatted on it. Or more adaptively for the right click menu to add the last used paste special option after Paste.
Steve

[Steve_Edmonds]

This is an interesting discussion and possibly useful to the UX team. There seems to be usage methods that are each the obvious (to the participant) route to take. Even when programming in assembly I favoured reusable code and jumps. Smaller code and easier maintenance, but may be that is just the way I look at things.
Steve

[Tom_Davies1]

Hi
Actually i find even then styles help quite a bit. I don't use Master
Documents or sub-documents yet but the basics help.

For the new document you can;
1. right-click on the style, such as "text-body" (although i think
it might be better to create a new one by copying that to a new name)
2. "Modify style"
3. Watch the changes ripple throughout the document.
Although i tend to just stay with my preferred "house style" anyway.

I sometimes do posters for my company's (well my bosses) client groups
and still find styles quite useful. They give a good base-line and
then i do some direct formatting to make it more wacky and
eye-catching (but not tooo much).

Regards from
Tom

[Felmon_Davis]

Hi, Tom and others.

I am finding this discussion to be intellectually stimulating though I have

no idea as to the mechanics involved in developing or using master documents.

What you write about saving time is most likely very true. However I have

probably never written a document with more than about a dozen paragraphs and I have no idea where to look for the study materials that you say can be read in ten minutes thus immediately saving twenty minutes to an hour.

Having shouted the glories of styles, let me also say that their benefit comes from doing the same types of documents over and over again. If I were using Writer to create a wide variety of (relatively short) documents, then styles might make me go mad. To use them properly would require me to create dozens of templates and styles covering every type of possible situation. That might take far more time than just typing the dang letter and hitting <ctrl-p>.

thank you for injecting this into the discussion. the use of styles is not primarily a matter of inducing uninitiated into a new technology, it's a matter of fitness to purpose (in my opinion).

for one thing, in OO and LO one is always using a style, the 'default style', but if you mostly write short bits then probably don't need styles (the default style suffices) though I myself change the default to indent the first line of new paragraphs and change font face and size to what I prefer.

more complicated work or specially formatted jobs prosper from styles. I bring out a bound volume of essays every yr and shudder to think what would be involved without a basic template for it.

As for master documents, I wouldn't go down that road unless I were doing a truly massive project, in which one minor corruption could ruin the entire document.

I have found master documents a bit unwieldy for my essay collection project. the essays come from diverse authors so I have to do a fair amount of individual editing. then a good template cuts down on some of it and it's just as easy (for me) to pull it all together into one book (file).

F.

[Mark_Bourne]

Virgil Arrington wrote:

How would you define a paragraph style to handle a dictionary entry
such as this:

*canuscere*/v.t./ to know, to be familiar with.

I see my formatting was lost on that example. The headword
"canuscere" would be in 11 pt. boldface, while the rest of the line
would be in 9 pt. normal, except that the "v.t." would be italicized.

You've got two things going on here, as I see it. The *paragraph* style
would determine the primary font and style of the paragraph (9 pt.
normal) along with paragraph indents and any extra space above or below
the paragraph. The boldface "canuscere" and italicized "/v.t./" would
not be controlled by the paragraph style. They could either be
controlled through direct character formatting, or with a character
style, (defined as either 11-point boldface or 9-point italics). Then,
you would apply the paragraph style to the whole paragraph and then the
character style to the individual words to which they would apply.

Quite honestly, I rarely use character styles, but in this case where
you're changing two characteristics (9 points to 11 and normal weight to
boldface), the character style would help ensure consistency throughout
the document. With the italicized "/v.t./" I don't see any advantage to
using a characters style as you're only changing one feature (normal to
italics). Just highlight the text and hit <ctrl-i> and you're done.

Until, for example, you later decide word types should be blue as well as italic... If you've just hit ctrl+i all the way through to make them italic, you'd have to find all occurrences and change them all again. If you've defined and used a character style, you'd just change the style once and all the word types would turn blue.

[Virgil_Arrington]

Mark,

You're absolutely right. I stand corrected.

Virgil

[rmg]

Hello rmg,

When you shut down after pressing [Goodbye] (which you do, it's a
dedicated machine) you get '/usr/lib/libreoffice/soffice not
responding'. If you close the front end with the close button you don't
- but then it doesn't do its cleanup.

Any suggestions?

soffice doesn't exist there on my system; I have /usr/bin/soffice which
is a link to /usr/lib/libreoffice/program/soffice

Quite right, my mistake, it's '/usr/lib/libreoffice/program/soffice not responding' and the link from /usr/bin is there too.

I suggest you check your spreadsheet for references
to /usr/lib/libreoffice/soffice and if they exist, change them
to /usr/bin/soffice

No references anywhere in the spreadsheet or the macros to <anything>soffice.

[Cley_Faye]

​You should check the macro to find how it's closing libreoffice (which
function is called or something like that). Maybe there was a change in API
since the OOo time and it is dependant on something deprecated/broken.​

[krackedpress]

Yes, having a set of codes that you can reuse in your programming is a real time saver over writing everything from scratch every time you need to create a new program package for "the boss". What I stated was that when I was a programmer, my boss[s] wanted all the code in one program and not have included modules of code. So you take all of your "procedures and functions" and place them inside the dingle file for the entire program. 20, 50, 100, 300, etc., pages of printout per program/package was the normal coding in my days as a mainframe programmer. COBOL was popular, though there were other better and worse languages that were used to do what was needed. Ever write a RPG II/III program? Worse to debug and modify. My first job was typing punch-cards and create paper-tape "program and data storage". That is really dating the types of equipment I had to deal with. I even did some Assembly module/routine coding with FORTRAN as the I/O for it.

Yes, having small code blocks that are easy to understand and reuse/modify is the key to the modern coding mindset and standards for doing things.

But, not all of us started out programming with that mindset as part of the programming skills taught in the educational and business environment. Now it is.

AS I stated earlier in this thread, I never got into learning and using Styles. I just never had the time or the "burning need" to do so. Then there is the compatibility issues of making a document with LO styles and then saving it as a .doc or .docx file format with MSO users taking that file[s] and modifying it and sending it back to you and your LO Writer to do more edits. I was told months and months ago that these styles would not "translate" well to MSO use and it would be better not to use styles at all for this type of cross platform and office suite editing. A great number of the documents I have created and edited over the past few years were for MSO users. I tend to stick with the .doc format [for text documents] so it is easier on the compatibility front between Writer and Word.

So using the "Underwood" type of mindset for modifying and "enhancing" a document, that will be edited by both Writer and Word users, may be better than dealing with Styles. So I have not really looked into using them in my work. Others seem to think that that style of work is too "old school", but it is not for many cases.

Yes, learning Styles would be a good idea, for those who have the time to do so. I have little time to learn in and keep up with the demands of my available time using a desktop or laptop. Half of my day seem to be me in a bed with a few pillows propping me up to see past my toes. That is the life of a guy with my back/neck/shoulder injuries. What time I can sit here and type these emails is a "gift" of my pain management routine. I have too much on my "plate" that takes up my time typing. Adding learning to use styles is not one of them. A new one was added by a police officer at my apartment "complex" asking me to monitor the computer center, 10 floors below my place, for illegal downloads, porn, and even the possibility of someone here using those computers for viewing child porn from overseas sources. When a police officer asks you to help with things like that, your answer should be yes.

[Virgil_Arrington]

I agree that sharing documents between users has been, for me at least, a real hindrance to using styles. I would create a beautifully styled document and then send it to someone who edited it using the Underwood method. When I got it back, it was a mess, so I would clean it up with styles, edit it some more, and send it back, only to have it come back a mishmash. And, at the time, we were both using MSO! (again, all things to all people.) I'm sure the person on the other end was cursing me for my use of styles just as much as I was cursing them for living in the typographic stone age. It was hard enough for me to convince my own employees to use styles (I never succeeded), I didn't dare try to convince somebody else's employees.

As far as translating styles between LO and MSO, I've found that they generally translate rather well. The primary exception that I've seen is in automatically numbered/bulleted and outline numbered paragraphs. LO and MSO handle numbering differently and that usually doesn't translate well. But, I generally try to avoid mixing word processors when sharing documents. Usually, I try to find out what the other person is using and use the same thing. I have several programs available to me, so I can usually work with anything I get.

Virgil

[rmg]

I was wondering about something of the sort. The closing is done with

if HasUnoInterfaces(doc, "com.sun.star.util.Xcloseable")
     doc.close(TRUE)
else
     doc.dispose()
End if

  as I said lifted straight from the macro examples; the Libreoffice API reference seems to say that's right.

doing 'killall soffice' immediately before shutting down gives 'No process found' but it finds the blasted process when it shuts down. Weird.

[Cley_Faye]

​I'm not very fluent in LO API, but according to the documentation (
http://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1util_1_1XCloseable.html)​
XCloseable.close() must be called before XComponent.dispose(), so maybe you
can try this:

​
if HasUnoInterfaces(doc, "com.sun.star.util.XCloseable")
    doc.close(TRUE)
End if
doc.dispose()

​Also note that it's XCloseable with a capital C. I don't know however if
it's case-sensitive (the doc seems to say it's not) but it wouldn't hurt to
check this too :)​​

[rmg]

​​
if HasUnoInterfaces(doc, "com.sun.star.util.Xcloseable")
     doc.close(TRUE)
else
     doc.dispose()
End if

  as I said lifted straight from the macro examples; the Libreoffice API
reference seems to say that's right.

​I'm not very fluent in LO API, but according to the documentation (
http://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1util_1_1XCloseable.html)​
XCloseable.close() must be called before XComponent.dispose(), so maybe you
can try this:

​
if HasUnoInterfaces(doc, "com.sun.star.util.XCloseable")
     doc.close(TRUE)
End if
doc.dispose()

Had a fiddle with that. doc.close and doc.dispose are alternatives, calling doc.dispose after doc.close gives an error.

To reduce the possible unknowns I simplified the [Goodbye] routine to do just

    doc=thiscomponent
    doc.close(TRUE)
end sub

without testing for hasunointerfaces - because we know this one has. Still gives '...../soffice not responding'.

Which I think definitely ties the problem to the doc.close(). I'm being forced to the conclusion it's a 'feature' and you get to live with it.

​Also note that it's XCloseable with a capital C. I don't know however if
it's case-sensitive (the doc seems to say it's not) but it wouldn't hurt to
check this too :)​​

Yes, the book also says it's not case sensitive and I have to admit I've played fast and loose with case elsewhere without ill effect. And anyway the minimalist Goodbye without that still gives the problem.

[pitonyak]

Case is usually not an issue. I think that with case, you must be right on with case for enums the first time that they are used (like when you set a font weight to BOLD). I do not know if it matters while specifying a an object or service when you use CreateObject or not. Apart from that, I am not aware of case issues in Basic.