Re: [libreoffice-users] Re: convert to pdf - failing
At 11:55 30/07/2012 -0700, J Taylor wrote: You do not need a PDF Converter. In Libre Office Goto > File > Export as PDF - Job done. You are right, of course, that LibreOffice provides a useful "Export as PDF" function. But it may be worth mentioning that it is still useful to have a virtual PDF printer installed. If, for example, you are printing from LibreOffice as a brochure, you cannot see exactly what will happen using Page Preview, and there is no brochure option in Export as PDF. You can save a lot of wasted paper by creating test prints of your brochure as PDF using a virtual PDF printer. Brian Barker -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] pdf creation issue on a single file?
At 15:42 28/07/2012 +0200, Hylton Conacher wrote:
I have an rainfall.ods document that has 24 tabs. Two of the tabs
contain figures and the balance contain graphs of the figures. I
recently experienced a problem, it would seem after my last tab
addition, that prevents me from creating a PDF file of the selected
sheets(12). The PDF export works fine on other files regarding
`Export as PDF', why not on this file?
At 18:12 29/07/2012 +0200, Hylton Conacher wrote:
Further to this issue it would seem that only the last created graph
is being exported (but this is NOT the last selected Tab) as when I
view the exported PDF, only a single page shows, instead of approx 12.
Easy - now that I've looked at the document. You have a print range
defined on sheet 20 of 24 ("Ann Monthly Comp"). You may be assuming
that - since this print range is set to "entire sheet" - that it will
have no effect on the output, but that is not so. If you have a
print range set anywhere in your document, it affects the whole
document, and no other sheets will print except where they, too, have
print ranges defined. And print ranges, it seems, apply equally to
Export as PDF as to Print itself.
Remove the print range from the rogue sheet (Format | Print Ranges >
| Remove) and everything is hunky-dory.
I trust this helps.
Brian Barker
--
For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Other SQL question as it affects Base
Mark Stanton wrote: Ok, this is, then, quite an interesting idea. The problem is that you've got nothing reliable in your data to relate one date to the next (by the looks of it). You're only taking readings at roughly monthly intervals. Once a month, I get a bill from the local power company that contains the following data: the date the meter was read the previous billing cycle, its reading, the date the was read for this billing cycle, its reading, and the amount due. I would think this is very reliable: they want to get paid. And with bill in hand, it is not very difficult to enter the data into the table. If the accounting people do not do this on a regular basis, they are not likely to have a job. For an individual, it is all about diligence. Use it, and the results will be accurate and reliable. Without, your right, the results are useless. [Garbage IN Garbage Out.] A good, purely SQL, solution to this would be to code a stored procedure that is guaranteed to hand out successive numbers, and then you can use that to do the arithmetic you've done already. You'd want another table that stores the current value of your counter, and your entry data process would get the next number for your next entry and update the table. You could do it by finding the maximum number already allocated in your table and add one (or whatever). This is far more complex than what I have created. If you're prepared to bet the ranch on having one reading every month without fail, you could find the lowest date and then generate an integer singly increasing index on month's since first date. That'd be two more SQL selections. I agree about databases in general of this type. But it seems to me that not having accurate data in is a problem that should be handled in another way. The query is designed for using available data to provide answer to the person who uses it. It can only give as good information as what is given it. I'm very diligent when it comes to data like this. I'm well aware of the phrase GIGO. I make sure that correct information is entered when it needs to be entered. (I don't put garbage in.) So, I don't get garbage out. The problem with what you've done is that there's no guarantee that it'll continue to work. It probably will, by the looks of it, but it's only a fortunate side effect of something that is not guaranteed. Strange you should write this. The query matches algebraic equations. I'm just not lucky: I am using the laws of algebra. It will always work. Yes, the problem is in the accuracy of the entered data. Diligence is the key. Addendum: While I have not added it yet, I kept track of the probably amount for this billing cycle using today's date, today's reading, the average KWH usage per day, the number of days, and the cost per KWH for the previous billing cycle. I update this more than once a week. In a business environment you'd get fired for something like that, and quite rightly! In an amateur environment, you're getting away with it, which might be good enough for you. How wrong you are! I too have some business experience. Mine proves you wrong. I used this process on paper during the years 1981 and 1982. During each year. I used four columns: week ending date last year, sales for the week ending on the date, week ending date this year, and sales for the week ending on the date. In my dry cleaning store, the week ended on Mondays. The first record had data for 1980 (by another manager) and 1981. The second had data for 1981 and 1982. The first proved that I was doing quite well as compared to the previous manager (1981 vs 1980). I knew this by mid summer, but the home office (in another city) did not know until about 3 months later. (There was a 37.5% increase in sales. That was nice.) The second indicated a drop in sales (the Regan recession). I saw that a couple of months before it was noticed in the home office. I knew what 4 other managers in the Baton Rouge area did not know because I had the data. Why did the owner of the store visit my store to see my data every time he was in Baton Rogue? I made sure the data was always kept up to date. You see, you are right. The question is: How valid is the data that is being used? I made sure my data was valid. This is why rather than being fired for doing this, I was later moved to Lake Charles to take over a much larger store that included a laundry plant. I was even given the job of training new managers, but that required more than I could handle. The next alternative is pulling the data in date order (yes, I know it's almost certainly in date order already, but if you don't make sure then you can never enter historical data [you're sure to miss entry for some reason some day]), and then run through the table doing the sum between last month's data and this month's. The bills I get makes entering historical data quite possible since each bi
Re: [libreoffice-users] pdf creation issue on a single file?
On 29/07/12 23:50, MiguelAngel wrote: El 29/07/12 18:12, Hylton Conacher (ZR1HPC) escribió: Hi Miguel, On 28/07/12 18:07, MiguelAngel wrote: El 28/07/12 15:42, Hylton Conacher (ZR1HPC) escribió: Hi, I have an rainfall.ods document that has 24 tabs. Two of the tabs contain figures and the balance contain graphs of the figures. I recently experienced a problem, it would seem after my last tab addition, that prevents me from creating a PDF file of the selected sheets(12). The PDF export works fine on other files regarding `Export as PDF', why not on this file? I was using LibreOffice 3.3 and have since updated to LibreOffice 3.4.5 OOO340m1 (Build:1505). Unfortunately the newer version is unable to `Export as PDF' on the selected TABS either!! What could be wrong? There are no special characters in the sheet names bar possibly a space. I will gladly send this file to anyone who can assist as I need to create and post to a public user mailing list a PDF at the end of the month. Help is much appreciated Hylton Thank you for commenting on the OP's initial problem, and not a Linux Windows word flame-war that bears no relation to the subject line, despite some valid suggestions being valid. Verify you have not marked in the same tab the option: Embed OpenDocument file. How could I check this via the GUI? I recreated the last graph and made sure there were no 'embeds' of any kind. Could non-standard fonts i.e. not Arial, also play a part? Further to this, issue it would seem that only the last created graph is being exported( but this is NOT the last selected Tab) as when I view the exported PDF, only a single page shows, instead of approx 12. Hylton Hi Hylton, sure I have not explained with the required detail. The option is in: Menu/File/Export as PDF/[General] - General - Embed OpenDocument file. This option is not available on my version of LO 3.4.5 only 'Embed Standard fonts' is available, which is not selected. If this option is enable the only chance is to export the complete document. This option embed the ods document in the pdf file, and if you later open this pdf in LibreOffice the ods document is open. IMO a very interesting option to share a document, an accurate view plus an edit file option. About other non related things with your question, you are right, IMHO people would be better answer what it is asked, and if they like to comment about other things start their own thread. Too much blah blah blah, with few helping answers. Thanks for the idea, but alas the problem persists. I have Cc'd you and include the file as an attachment, that I know will be stripped by TDF for the mailing list but you should receive it. Once you open the file in Calc, select all the tabs from July to General, Choose File: Export to PDF, Choose only selection, save the file on your system and then re open it with Adobe Acrobat to check all pages exported. If they did what version of LO are you running? Regards Hylton -- Hylton is a Lions Club member of Lions Club of Fish Hoek (District 410A) http://www.fishhoeklionsclub.org.za being part of the worlds largest NGO -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Other SQL question as it affects Base
Mark Stanton wrote: As far as I remember it's explicitly stated in the SQL definitions Id fields should not contain data entered by users You can't rely on them not least because often they're automatically generated by the system. They bear no necessary relationship to the data. Mark Somewhere there is disconnect. We seem to be talking at each other. The table I put in my earlier email had three fields: the primary key, ID, which was automatically generated by Base, the date the meter was read, and the reading. The field, ID never has contained data entered by me. It is in First Normal, Second Normal, etc. Form. When use a left join to join this table to itself, the first three fields of each row are the three fields of the table and the values of the ID field are unique. What about the other three fields of each row of the query? For each row, ID in the fourth column is always one larger than the ID in the first column. What relationship does the values of ID have with the values of the dates and the meter readings? None. I'm only using the two ID fields to place the rows of data where I want them to be. It so happens that the ID field consists of integers. More importantly, being integers, they can be used to order the rows. This is want I did with them: order the data. I just used arithmetic to say what that order is. Concerning the query that I posted earlier: the values I got using it are identical to the values I have in a spreadsheet to track these statistics. I have 41 rows in the table resulting with 40 rows of query output. That is 200 cells containing data which match to the data in the spreadsheet. Here is where I think we are not paying attention to each other. The usual ON expression involves setting the primary and foreign key as equal. I'm saying that there are situations that arise between tables in which equality in the primary-foreign key pair is not what is required. I have given an example for which a simple arithmetic equation works. In fact, I think there is a class of queries that fit the case: "primary key" = "foreign key" + n where n is a positive integer and the table is joined to itself. When a company compares weekly, monthly quarterly, or annual sales year over year, they are going to use something very similar to this. This can be used to determine quarter over quarter, etc. as well. How else do you create a query that has weekly data for a store for last year on the left and the data for the same store for this year on the right? [I would use "foreign key" = "primary key" + 52 in a LEFT OUTER JOIN.] Now as far as using more complex algebraic expression in a JOIN, I agree that this is a "little far out". It really depends upon how the primary and foreign keys are generated. For example, the primary key could be the positive integers (counting numbers). The foreign key could be the cubes of the positive integers. Then if we want to join the rows of one table with the rows of another table so that the foreign key is the cube of the primary key, we would have to use "foreign key" = "primary key" cubed in the ON expression. Now I agree we don't usually use the cube of positive integers as the values of a foreign key. So this is definitely "far out". My point is that it does meet the requirements for a query that could produce useful information. Just because the first four values for the foreign key is 1, 8, 27, and 64, that does not mean these are not distinct values that could not be used to order the rows of a table by them. For the most part, people will continue to use positive integers with unit increments in their primary keys. This means the foreign keys will have the same file type. For them, what I have written will probably make little sense. And they may not need any of the other possibilities. And I also agree, most of these possibilities serve no real purpose based upon how we do things now. Some of these primary key properties we have mentioned might be very difficult to impossible to define for a table. From the beginning, my only purpose is to question as to what is possible given the characteristics of the primary and foreign keys. Again, I realize that what is possible may not be what we would want to do. It may not serve a useful purpose even though it works and it follows all the rules of SQL. --Dan -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-users] Re: convert to pdf - failing
On Mon, 30 Jul 2012 10:04:36 +0100, Sharon Kimble wrote: >I'm trying to use this command to create a pdf file from an .odt file >but its failing for some reason. >- > libreoffice --headless --invisible --convert-to pdf test.odt >- > >Can anyone help me in getting it to work please, as its needed for a >bash script. $ unoconv -f pdf file.odt works wonderfully in Arch, AFAIK the last time I had to use it in Ubuntu I needed to replace the Ubuntu version with the upstream version from the author's web site. -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-users] Re: convert to pdf - failing
You do not need a PDF Converter. In Libre Office Goto > File > Export as PDF - Job done. Tink. -- View this message in context: http://nabble.documentfoundation.org/convert-to-pdf-failing-tp3998412p3998516.html Sent from the Users mailing list archive at Nabble.com. -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Other SQL question as it affects Base
El 30/07/12 2:08, Dan escribió: Mark Stanton wrote: Keys are intended for the internal workings of the database, they are not meant to be used like this. What you want is the WHERE clause, or occasionally the HAVING clause, matching or excluding rows based on their data. Keys are NOT data and should not be used as such. Regards Mark Stanton One small step for mankind... I have a table, Reading, that contains three fields: ID, Date, and Meter. Date is the date the meter is read, and Meter is the meter reading. I want to know how much electricity (KWH used) I have used each month. The query below will provide that information: SELECT "Ending"."Date", "Ending"."Meter" -"Beginning"."Meter" AS "KWH Used" FROM "Power". "Reading" AS "Beginning" LEFT JOIN "Power". "Reading" AS" Ending" ON "Ending"."ID" =1 + "Beginning"."ID" Perhaps you are right about keys being intended for the internal workings of the database. While I don't have an example of one key being the multiple of the other key, it is possible. It just might not have any practical applications. --Dan I have used a sentence like next with Firebird, but I don't know if your database lets to use SELECT like a field. SELECT R_End.Date, (SELECT R_Beg.Date FROM Reading AS R_Beg WHERE R_Beg.Date = (SELECT DISTINCT MAX(R_Look.Date) FROM Reading AS R_Look WHERE (R_Look.Date < R_End.Date))) AS Beginning_Date R_End.Meter, (R_End.Meter - (SELECT R_Beg.Meter FROM Reading AS R_Beg WHERE R_Beg.Date = (SELECT DISTINCT MAX(R_Look.Date) FROM Reading AS R_Look WHERE (R_Look.Date < R_End.Date AS KwH_used FROM Reading as R_End (SELECT DISTINCT MAX(R_Look.Date) FROM Reading AS R_Look WHERE (R_Look.Date < R_End.Date)) Search the maximum date before the actual row date, which lets to get the previous values to the actual row date. Miguel Ángel. * Inglés - detectado * Inglés * Español * Gallego * Italiano * Inglés * Español * Gallego * Italiano -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Other SQL question as it affects Base
Ok, this is, then, quite an interesting idea. The problem is that you've got nothing reliable in your data to relate one date to the next (by the looks of it). You're only taking readings at roughly monthly intervals. A good, purely SQL, solution to this would be to code a stored procedure that is guaranteed to hand out successive numbers, and then you can use that to do the arithmetic you've done already. You'd want another table that stores the current value of your counter, and your entry data process would get the next number for your next entry and update the table. You could do it by finding the maximum number already allocated in your table and add one (or whatever). If you're prepared to bet the ranch on having one reading every month without fail, you could find the lowest date and then generate an integer singly increasing index on month's since first date. That'd be two more SQL selections. The problem with what you've done is that there's no guarantee that it'll continue to work. It probably will, by the looks of it, but it's only a fortunate side effect of something that is not guaranteed. In a business environment you'd get fired for something like that, and quite rightly! In an amateur environment, you're getting away with it, which might be good enough for you. The next alternative is pulling the data in date order (yes, I know it's almost certainly in date order already, but if you don't make sure then you can never enter historical data [you're sure to miss entry for some reason some day]), and then run through the table doing the sum between last month's data and this month's. Of course, if you do ever enter data out of order the first strategy here won't work, or you'd have to manually reallocate your sequence numbers. Regards Mark -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Other SQL question as it affects Base
As far as I remember it's explicitly stated in the SQL definitions Id fields should not contain data entered by users You can't rely on them not least because often they're automatically generated by the system. They bear no necessary relationship to the data. Mark -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] Other SQL question as it affects Base
Jay Lozier wrote:
On 07/29/2012 08:08 PM, Dan wrote:
Mark Stanton wrote:
Keys are intended for the internal workings of the database, they are not meant
to
be used like this.
What you want is the WHERE clause, or occasionally the HAVING clause, matching
or
excluding rows based on their data.
Keys are NOT data and should not be used as such.
Regards Mark Stanton One small step for mankind...
I have a table, Reading, that contains three fields: ID, Date, and Meter. Date
is
the date the meter is read, and Meter is the meter reading. I want to know how
much
electricity (KWH used) I have used each month. The query below will provide that
information:
SELECT "Ending"."Date", "Ending"."Meter" -"Beginning"."Meter" AS "KWH Used" FROM
"Power". "Reading" AS "Beginning" LEFT JOIN "Power". "Reading" AS" Ending" ON
"Ending"."ID" =1 + "Beginning"."ID"
Try the following
SELECT date, meter FROMReading WHEREdate = initial date OR date =
ending date
(date = '4/1/2012' OR date = '4/30/2012' - using correct date format for your
system)
Sorry, but this does not give the same results as my query. Yours will
give the
date the meter is read and the reading for each date in the "Reading" table for
the two
listed in the WHERE clause. The question the query is suppose to answer is How
many KWH am
I using each month? Your query does not answer this question. In my table, I
have 41 rows
of data. When I run my query, I get 40 rows as my output. Your query has only 2
rows in
the output.
Here is the first 4 rows of the table.
ID End DateEnding
1 04/16/0916717
2 05/15/0917125
3 06/17/0917418
4 07/20/0917735
I Added some things to my query:
SELECT "Beginning"."Date", "Ending"."Date", DATEDIFF( "Ending"."Date", "Beginning"."Date"
) AS "Days", "Ending"."Meter" - "Beginning"."Meter" AS "KWH used", ( "Ending"."Meter" -
"Beginning"."Meter" ) / DATEDIFF( "Ending"."Date", "Beginning"."Date" ) AS "KWH/Day" FROM
"Power"."Reading" AS "Beginning" LEFT JOIN "Power"."Reading" AS "Ending" ON "Ending"."ID"
= "Beginning"."ID" + 1
WARNING: This was done using Base as the front end and MySQL 5.1.x as the back end. If you
try this using a Base embedded database, you have to change the DATEDIFF() to
DATEDIFF('dd', "Ending"."Date", "Beginning"."Date")
The results of my "new" query are:
Date Date Days KWH used KWH/Day
04/16/0905/15/0929 408 14.069
05/15/0906/17/0933 293 8.8788
06/17/0907/20/0933 317 9.6061
Perhaps you are right about keys being intended for the internal workings of the
database. While I don't have an example of one key being the multiple of the
other
key, it is possible. It just might not have any practical applications.
Keys are intended in an relational database to uniquely identify each row of
data.
While often being integers any unique string or group of columns can be a key.
For
example, if there is only one date entry for each date you could use the date
as a key.
The reason integers are typically used is that they allow the possible multiple
entry
of a date in a table because each entry would assigned a different integer.
The key
value id = 100 has no required mathematical relation to the key value id = 200,
mostly
likely all this means is there are 100 entries since 100th entry. Otherwise
there may
no connection be the two entries.
For example, two companies could have the same name - Fred's Wholesale Produce
but be
located in different states (Kentucky and Indiana for example). A key of
company name
and state is possible but often awkward to use when accessing other tables such
as
orders or purchases. Integer id's allow for accessing other tables by using on
field
which happens to a unique integer.
An Orders table might have the following initial columns: id, id_vendor,
id_PO_items
PO, Date etc. The id is a unique key for the Orders table, the id_vendor refers
to the
id in a separate vendor table which might have the vendor contact information.
The
Id_PO_items might refer to a table which lists each item order with appropriate
vendor
information.
--Dan
Basic theory: relational databases are based upon Algebra including the
Algebra of
Sets (unions, intersections, Cartesian products, Subtraction of sets, etc.). In fact some
of the early complaints about the structure of relational databases was that it was too
mathematical.
Observations: JOIN ON clause is based upon the Algebra of Sets. The ON expression is
algebraic. The WHERE clause is also algebraic.
My point: If there is an algebraic expression that describes the relationship
between a primary key and its foreign key, then that expression can be used as the ON
expression. If further restrictions are needed, then these belong in the WHERE clause.
This is about the theoretical rather than what has bee
Re: [libreoffice-users] re-merging a master document
On 7/29/2012 2:49 PM, Gabriel Risterucci wrote:
If I understood correctly what you want, in the navigator you can do right
click->refresh->all (or something along this line, I use a different
locale). This will refresh all subdocuments.
Thank you, not only 1 way - 3 ways
--
Bill Drescher
william {at} TechServSys {dot} com
--
For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] re-merging a master document
On 7/29/2012 2:53 PM, Brian Barker wrote:
At 13:32 29/07/2012 -0400, Bill Drescher wrote:
Is there a way to have the master document merge the
subdocuments again without closing and opening it ?
Try Tools | Update > | Links (or Tools | Update > | Update All).
I trust this helps.
Brian Barker
Thanks Brian, you are terrific.
--
Bill Drescher
william {at} TechServSys {dot} com
--
For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-users] convert to pdf - failing
On 30-07-12 11:04, Sharon Kimble wrote: I'm trying to use this command to create a pdf file from an .odt file but its failing for some reason. - libreoffice --headless --invisible --convert-to pdf test.odt - Can anyone help me in getting it to work please, as its needed for a bash script. Thanks Sharon. Sharon, Print your .odt file to a file (it will need the .ps extrension). Then use ps2pdf to make it into a .pdf file. All if you're on Linux. I don't know anything of Windows. Joep -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
[libreoffice-users] convert to pdf - failing
I'm trying to use this command to create a pdf file from an .odt file but its failing for some reason. - libreoffice --headless --invisible --convert-to pdf test.odt - Can anyone help me in getting it to work please, as its needed for a bash script. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk/taste/index.html efever = http://www.efever.blogspot.com/ efever = http://sharon04.livejournal.com/ Debian 6,0.5, Gnome 1:2.30+7, LibreOffice 3.5.5 Registered Linux user 334501 -- For unsubscribe instructions e-mail to: users+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
