Re: [discuss] OpenOffice Verson of Outlook?
Le Ven 14 mars 2008 16:13, Bret Busby a écrit : Interestingly, Star Office 5.2 had much interesting functionality, such as email, task scheduling, calendar, etc, and the functionality of that stuff, was deleted when Star Office 5.x was transformed into OpenOffice. SO tried to be an autonomous integrated entity that praticaly took over all your desktop. It was massively unpopular with users, since SO had major problems working with anything not bundled within SO, and a lot of the applications bundled in were poor replacements of existing alternatives. The refocusing of SO on core office functionalities saved the product IMHO. The functionality you dream about was badly implemented, and a few good tools have more value than many bad ones. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Openoffice calc/writer layout change between Windows Linux version
Le Jeu 10 janvier 2008 04:02, kstan a écrit : Hi Michael, Thanks for your reply, I mean, I open a same file in Windows Linux, the layout change. The font is same (I did try use default, freeserif, aria and etc) The font is the same in the document but is it available on both systems ? If not the software will substitute whatever else is available that may have different metrics. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [discuss] Will Bug 48822 be worked on before the next major release
Le mercredi 21 novembre 2007 à 11:28 -0800, Mike White a écrit : Personally, I find this response a bit disturbing. If Open Office is trying to take over corporate World, then Open Office should not be telling users that they have to adapt to some arbitrary standard. This is not an arbitrary standard and it was written for the corporate world by huge corporations. Which does not mean dates in legacy quirky non international formats should not be handled. But anything that rejected ISO 8601 does not play in the big corporate space. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] good suggestions for OO.o
Le mercredi 21 novembre 2007 à 14:55 -0600, Alexandro Colorado a écrit : On that line... I was onced asked if it can be done with webdav and exactly how can you get documentation on having an enviroment with webdav? http://httpd.apache.org/docs/2.0/mod/mod_dav.html (basically just install mod_dav in any recent apache and use the Dav On directive. The rest is standard apache) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] Re: IMPORTANT
Le Ven 12 octobre 2007 12:20, Diabolic Preacher a écrit : On 12/10/2007, Florian Effenberger [EMAIL PROTECTED] wrote: In general, people are free to sell OpenOffice.org, our license permits that. ...but the media reports that important contributions like an optimzation solver and many other updates from various distro teams are not accepted upstream in cases where Sun wants to have the ownership of it or something. That's a different problem. You can't force third-parties to work through OpenOffice.org, you have to offer them conditions that make it worthwhile for them to work with you (a licensing that forbid third-party OpenOffice.org versions would in itself sufficient to make a lot of entities invest time on other solutions). Just as SUN may decide relinquishing a little control over OpenOffice.org may not be worth the extra contributions the project would get, other entities may decide having some code merged at OpenOffice.org is not worth the degree of control SUN asks over this code. I personally think SUN management has always mis-evaluated the balance of its open-source projects, and tends to value the short-term convenience of control over the long-term benefits of more open approaches. In particular SUN's current problems with .Net-Mono-OOXML/Microsoft-Novell can be traced directly to the years it kept an iron grip over Java, focused on the lucrative Solaris J2EE segment, and prevented anyone else from turning Java in a decent desktop Linux technology. Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: paste unspecial
Le Mer 10 octobre 2007 09:38, Alan Lord a écrit : Datatude wrote: Jonas Svensson wrote: One thing I find very annoying in both MS Office/Word and OpenOffice.org is that paste always keeps formatting when pasting from another program. Is there a way to reverse the paste setting so that regular paste removes formatting and only special paste keeps formatting? That is a great idea. I also would like to be able toggle this parameter. Somewhere in the settings this should be user configurable. Yes please. I spent the day undoing gratuituous CutPaste formatting -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OpenOffice 2.3.0
John B Kittredge a écrit : I just saw on your website that IBM is adopting much of OpenOffice and coming out with it's Symphony. Symphony is available now but Symphony is an Openoffice fork so it likely uses the ODF formats which have nothing in common with the old lotus formats -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Revision control of OOo documents
Le Mar 12 juin 2007 18:08, Mathias Bauer a écrit : Would it help to use the WebDAV API of, say, SVN and let OOo store each stream separately into a WebDAV folder, this folder becoming the representation of the OOo file? a folder is probably the way to go. Probably adding a special sequence in the name to limit collisions with users-created folders Perhaps OOo would need to do some VCS bookkeeping besides that but could that be the way to go? I haven't looked at it closely lately but I seem to remember the Webdav versionning model was pretty simplistic and CVS-like. SVN is a little better but not much. IMHO if whould be really worthwhile to look at next-gen VCSes like git and mercurial instead : - they have a distributed model very close to how office people manage their documents - they don't need a webdav/SVN server set up somewhere - they don't require always-on network access to said server - they are fast (esp. git) - a a result SVN is losing traction pretty quickly With mercurial or git you could either have two users share docs via the VCS feed or one user with a local vcs backend used to track the changes in the docs people send him by mail. Maybe even an odx variant where a copy of the vcs db is embedded in the document (another big feature of modern FLOSS VCSes is they made it cheap and easy to manage small repositories, so you could have a repository dedicated to a single document) Or how would you suggest to make OOo aware of the VCS backend? Making OOo aware of the backend is probably required. With collaborative work you get multiple branches/versions with change collisions, and the VCS can only resolve a part of them by itself. At some point you need a tool aware of the document format that presents a conflict-resolution UI to the user to select what should be kept. Also the people that would benefit the most from modern VCS-like tracking are not developpers but office workers, and they won't touch any tool that requires them to leave their office tool. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Styles Handling
Le samedi 21 avril 2007 à 17:10 -0500, Rod Engelsman a écrit : I, too, use styles extensively when I write but I find myself being frustrated and confounded at times. I believe the proximate cause of the problem is that the styles paradigm in Writer conflates different concepts which are in fact orthogonal and should be handled through separate, parallel, mechanisms. … Of the above categories, number 4 and, to a certain extent, number 1 are the only ones which, in my mind, fall under the paradigm of a Style. + 1000 … When you dig down deep enough into this issue, it seems to me that the root cause is that we have a program feature that's designed from the programmer's perspective rather than the user's perspective. You're sooo wrong here. Even OO.o developers are hopelessly confused. Because the thing is named styles and mainly used for 4. you find developers trying to treat everything as presentation. Even when as you've just noted whoever designed this intended it for more. It's real hard to design a good UI when you don't understand your own software concepts. Every part of the OO.o UI that uses styles for something other than presentation is a disaster because the designers try to make non-presentation actions behave as presentation. You have several content levels 1. basic text 2. intrinsic text attributes like langage (you can flip all the switches you want once a sentence is written in one language it won't autotranslate in another, an hyperlink stays an hyperlink, etc) ie semantics 3. document structure (organisation in chapters, etc) 4. presentation (fonts, colours, etc) A good tool lets you change a content level without touching lower levels. OO.o spends its time trying to force you to change everything at once, because everything is a style attribute, and no one ever untangled the layers (in the UI or in dev minds) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] Re: Styles Handling
Le dimanche 22 avril 2007 à 06:55 +, jonathon a écrit : Maybe. Example time: In an essay discussing the YiJing, one would use the Chinese glyphs for the names of the hexagrams. Typically, these glyphs are a single character. But that's not something that should require separate styles. That's something that requires OO.o noticing the input method changed, tagging text with the corresponding language and (optionally) declining styles according to this language (without requiring a cumbersome style switch) Can you elaborate more on the difference between document styles and templates. Trivially you can have a set of document types that share presentation rules (organisation graphic charter) but have different starting pages (the first 1-5 pages before the content, which depend on the document use) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] Multi language bar idea.
Le Mar 17 avril 2007 12:15, Sigrid Kronenberger a écrit : Hello Massimiliano, Am Tue, 17 Apr 2007 10:05:39 +1200 schrieb Massimiliano Cacciamani [EMAIL PROTECTED]: Multi language bar idea. I Can speak and write 3 languages (English, Italian, German), and I always thought that a good feature for Open Office should be a Multi language bar. This does already exist. :) IIRC support for multilingual documents was not really there today. You have to create mono-lingual documents or do ugly workarounds in styles -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Multi language bar idea.
Le Mar 17 avril 2007 13:13, Bernd Eilers a écrit : Using styles is not a workaround it´s a feature! ;-) No it's not. OO.o has a very powerful styling feature It's been used and abused for all sorts of things (langage, link objects) that have nothing in common with presentation. Styles are *not* a generic text attribute framework. Or rather they can be deep down but this concept should never permeate the UI (like it does now) I've lost track of all the UI bugs I've seen where the developper wanted to have things behave like presentation when for the user it's content just because both use styles and what styles are is not clearly defined today. Presentation is something that can be changed without altering the document meaning. Content should be preserved at all costs. You mix both you get UI disasters. Regards -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OpenOffice
Le Ven 16 mars 2007 10:14, Ian Lynch a écrit : On Thu, 2007-03-15 at 21:08 -0700, Benjamin Huot wrote: I agree that each is best for different uses. Using a graphical interface to run daemons would be asinine. And when you want to process multiple files, sometimes the command line is the only way. There is also the issue that most people are not fast typists. Bzzt. Shell history is your friend (even for slooow typers like me) and faster than rediscovering GUI menus -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Vote for more pretty default colors in charts
Le Lun 5 mars 2007 11:52, Chris Monahan a écrit : Ingrid wrote: What about to increase the current colour of chart from 12 to 24 or 36? Where do you expect that to be used? I would rate charts with 12 Software design is often said to involve laziness, this is not one of these situations We can't honestly expect everyone to use the software in the same sort of way if we're thinking of taking any real market share from MS Office. Yes, a lot of people use computers nowadays and they're all different, someone somewhere is bound to one day need larger charts. Besides in a corp setup you take the corp official color chart, which can have any number of colours in it (depending on the creative people whims), and there is no way an app like OO.o can dictate the right color chart lenght. (also you can have cross-company services that use two colour charts or more in common documents) -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Patch handling in OOo
Le Lun 5 mars 2007 16:15, Marcin Miłkowski a écrit : Hi Mathias, one more possible thing to consider: there are patches which are not seen as patches, as the patch submitter cannot change the status, and the owner of the defect doesn't see that there is a patch, see for example: http://qa.openoffice.org/issues/show_bug.cgi?id=72724 This is a patch, and the chances it will be applied are quite low, as nobody knows who is responsible for French dictionaries now. Is this counted as a non-processes patch or a defect in the statistics? FYI, Red Hat/Fedora (and probably others) consider OO.o the upstream for hunspell dictionnaries, and are patching all their desktop apps (not only OO.o but firefox...)to use those dictionnaries for spell checking http://rpmfind.net/linux/RPM/fedora/devel/x86_64/hunspell-fr-0.20060915-1.fc7.noarch.html (Fedora is sick of shipping a gazillon of different redundant dictionnaries) If OO.o can't maintain those properly (handling patches...), there is a problem BTW WRT http://qa.openoffice.org/issues/show_bug.cgi?id=72724 : œ is really different from o+e in french, you have words with œ and others with o+e and you can't do a blanket replace (see also http://jacques-andre.fr/faqtypo/lessons.pdf) -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Patch handling in OOo
Le lundi 05 mars 2007 à 17:40 +0100, Marcin Miłkowski a écrit : BTW WRT http://qa.openoffice.org/issues/show_bug.cgi?id=72724 : œ is really different from o+e in french, you have words with œ and others with o+e and you can't do a blanket replace But this is not about replacing. The code I used means for the spell-checker: please treat oe just as if it was œ when looking for suggestions (the word must be misspelled for this to start working). For some words, you'd get better suggestions. But if they are spelled correctly, it wouldn't complain or suggest that the word is misspelled. It's not about correcting automatically words spelled correctly into incorrect ones. Ok, as long as it won't accept coeur and propose cœur instead it's fine with me -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] OpenOffice Math
Le vendredi 19 janvier 2007 à 12:19 -0500, Patrick Ashley Meuser-Bianca a écrit : ATTN: OpenOffice.org I was just thinking that Math would be alot better if it supported Ket notation, as well as the circle add and circle multiply for matrix functions. There these and a few other symbols that I cannot think of right now that should be included as a part of OpenOffice.org Math. Just use a font that includes those symbols instead of the built-in Vera, for example DejaVu (dejavu.sf.net) -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] Open Office on Ebay
Le dimanche 14 janvier 2007 à 21:39 +, Rob Putt a écrit : This is absolutely unacceptable. Is there anyway we can prevent ebay users selling Open Office unless it is on a CD, Make the @openoffice.org download page so well-known no one bothers with the ebay pages -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] virus threat?
Le Lun 8 janvier 2007 21:18, Benjamin Huot a écrit : Its true I don't understand all the ins and outs of this as I am not a programmer, but I am very paranoid about losing my data, so I am not willing to risk possibilities even. I know that I can click no when I open up a file with macros in it so it won't execute and that I can set an setting in the options to keep macros from executing at all, but that won't work for my uses. And I realize that the default branch of OpenOffice.org does not yet and has no plans to include VBA support. Again, this will not work for my uses. IIRC you can disable interpretation of VBA macros in Office Files in OO.o preferences, so if you're sure you'll never need them you can avoid all the do you want to execute popup mess It seems you can't disable OO.o own macro langages though. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Site is charging $47 for your free product
Le samedi 11 novembre 2006 à 09:25 -0600, David Stiles a écrit : This site is charging $47 for your free product http://www-openoffice.com/ and I paid for it then found out it is free. Aren't they going against your user agreements? The license does not forbid commercialisation. Anyone is free to sell the suite. Since it's available as a free download, that means investing in communication and marketing (all of which are good for the project) -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Writing a MSc, PhD, DSc or a text book in Open office - P1 for Issuezilla
Le Mar 26 septembre 2006 08:29, Mathias Bauer a écrit : The problem is known but wasn't seen as a major problem (YMMV). Again: it doesn't influence load or save performance, it only hits the scrolling performance if you have a lot of images and you scroll back and forth a lot. You don't need a lot of images just a few high-res ones. When you have a page-wide high-res image, the interaction between pagination changes and image loading is deadly This of course would be less a problem if svg import/export was useable so you wouldn't need high-res bitmaps to produce quality paper documents. Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Writing a MSc, PhD, DSc or a text book in Open office - P1 for Issuezilla
Le Mar 26 septembre 2006 10:52, Ian Lynch a écrit : On Tue, 2006-09-26 at 09:56 +0200, Nicolas Mailhot wrote: This of course would be less a problem if svg import/export was useable so you wouldn't need high-res bitmaps to produce quality paper documents. Do Draw files not stay as vectors? If you have diagrams for documents surely best to originate them in Draw. Ok, it is a problem if they are sourced from elsewhere. I either don't have control over my diagram sources, or they use objects like visio shapes, which can only be exported in a semi-standard way using svg (and draw svg import/export sucks big time - never manage to have a result I could actually use with it). My personnal feeling BTW is draw and the odg format will fail and be replaced by svg and pure svg-oriented apps (inkscape...) mid-term. Draw is not a good enough app currently to make odg succeed by itself, draw is a minor part of the OO.o suite, while inkscape and friends are dedicated to vector drawing and are progressing by leaps and bounds. So I expect draw to progressively atrophiate like the HTML support in writer (or the SO mail client before), till someone higher up notices alternatives are actually way better and decides a thunderbird-like bundling. Of course not before a lot of NIH and effort duplication. My current workflow is : 1. beg a high-DPI bitmap version of the diagrams I need (600dpi), or create it in whatever source I I happen to use at the time 2. downsample it in The Gimp to 300dpi and right height/width (writer is bad enough without letting it actually resize diagrams, and most diagram programs are way worse than Gimp at AA) 3. save as maximum-compression png 4. import in writer In principle good support of vector graphics is essential for document processing since in most cases illustrations are best done in this format. However in practice Draw is not the app to use if you need vector graphics which can easily be imported/exported in other apps. (come to think of it it's no the app to use if you need bitmap graphics either, as it will blindly use the screen DPI when exporting) Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Office Writer - Envelope Printing
Le Mer 13 septembre 2006 01:31, Jonathon Coombes a écrit : On 13/09/2006, at 8:42 AM, Doug G wrote: PLEASE provide an envelope printing tool in Open Office Writer Open Office Writer lacks an envelope printing tool like MS Word. Actually Writer already has the functionality to print envelopes, perhaps you were just looking in the wrong place. I'm wondering if you actually made the OP a favour by pointing it to the current tool. It's pretty bad. regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [discuss] OpenDocument Formats WAS: Massachusetts goes to MS Office, butuses
Hi, Well, you know, given ODF is supposed to be proper XMl without the magic binary keys MS likes to use, the ODF foundation could probably release a small test app able to validate files in the wild. Of course that wouldn't catch problems like (purposeful ?) misinterpretion of some tags, but at least it would make sure files are technically sane. And tests can be added as mistakes are spotted in the wild. The problem with using OO.o as a reference is no user will ever accept it as a neutral test. Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] An idea for menu entry File/Recent Documents
Hi When all's said you're fighting the fact the recent documents list is a MRU (simplest programming model) while actual user needs are quite different (for example an accounting sheet may be opened every month, so even if other files have been opened more recently it should stick in the list). So an ideal list would be closely tailored to each user habits. I suspect assigning weights to the various parameters (last open time, number of accesses, current OO.o shell) and using some sort of bayesian algorithm (trained with actual uses of the list) might work best. Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Lack of OOo feature forces writer to move to Windows from Linux.
Le Lun 7 août 2006 14:45, [EMAIL PROTECTED] a écrit : To Rich [EMAIL PROTECTED]: special symbols: look at the two .png files I have attached to this email. I see no attachements in this mail microsoft has a field recently used, which is so extremely clever, that i am deeply impressed :) Also the char map does not group symbols into easy to find/manipulate blocks, etc if there is anybody able to let developers know about it, please do it, I have not yet explored how to do it http://qa.openoffice.org/issue_handling/pre_submission.html Please post the issue number there after you filled it. Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Lack of OOo feature forces writer to move to Windows from Linux.
Le dimanche 06 août 2006 à 09:23 +, Andrew Brown a écrit : Robin Laing [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: As both a Linux and OOo promoter, an article like this is quite interesting. I wonder how long until Microsoft gets wind of this and starts blowing it out of proportion. What is proportion in this instance? Well, since OO.o currently targets administrations, and administrations are the kind of orgs which produce long documents specs with revision marks... I'd say the proportion is pretty big. -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] New ideas
Le mardi 25 juillet 2006 à 12:38 +1000, André Wyrwa a écrit : SPECIFICATIONS Let's call that... REVISION TRACKING I see your point here in adding some kind of revision tracking. However, a left or extreme right column with certain symbols is a limited approach. It would be better to join that functionality into the changes tracking. You could simply assign a revision number to your changes and there would be a piece of UI that would enable you to select the revision range of changes that you want to be displayed. Does you little good when you have a printed version (let's not forget the aim is usually to produce printed documents, not documents which require OO.o to be read). The OP is perfectly right when he says you need to mark revisions graphically in specification documents (just open any public spec if you don't believe him) Basically what the OP asks for is : 1. § style which adds a symbol/image to the right or left of the § 2. ability to associate a § style to a particular revision -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] Anonymizing documents for QA bug reporting
Le samedi 22 juillet 2006 à 16:12 +0200, Mathias Bauer a écrit : Nicolas Mailhot wrote: Is there a way to take an OO.o doc, get all letters replaced with X or x, I don't know why I didn't see that immediately: replacing text will change the layout if you don't make sure that all relevant parts of text have the same size (not the same number of characters!). This can be complicated, e.g. when you have to replace text that wraps an image. The minimum requirement is that the number of lines in each paragraph will not change. Mathias, It's fairly easy to pad a § with new xxxs in that case. I don't believe text is a problem. 99% of the times the problem is in the part of the document which are hidden from the user : formatting rules, pagination, etc. Reproducing these rules exactly in a synthetic document is hard. Typing a few xs in contrast is trivial Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
Re: [discuss] Anonymizing documents for QA bug reporting
Le jeudi 20 juillet 2006 à 09:54 +0200, Mathias Bauer a écrit : Nicolas Mailhot wrote: Is there a way to take an OO.o doc, get all letters replaced with X or x, metadata stripped, embedded images replaced by blanks with the same sizes, and every other names (variables, bookmarks, fields, references, color/style names) anonymized? Replacing the text should be easy, also stripping the metadata. Replacing the images might be a bit harder, perhaps creating an empty image or metafile of the same size and replacing the embedded one is possible through direct file access. Another approach is replacing embedded images by links (to anywhere). You need to replace images by blank images of the same size or you'll hide pagination bugs linked to image size (not a theorical concern - one of those things is why I initially wrote this) Also a 2-color black or white png compresses well, so that would help documents fall under the upload size limit. I assume that the document should behave as before even with the broken links. I fear in many times the pagination would change The problem is: what else needs to be exchanged, what is really necessary and what's just paranoia? So we need a complete list and we need to dicuss what needs to be on it. As an example, why do you mean that color and style names need to be replaced? because humans will choose descriptive names which may include company name, and paranoïd users won't upload documents which may link them to a particular employer (see the Sun foo colors in the default palette) As most bugs happen on complex documents, most complex documents are created in corp-space and corporations don't like disseminating internal info for debugging purposes I suppose I'm far from the only one with knowledge of bugs but no way to report them. Yes, I totally agree. We could get much more (and better) bug documents and of course that would be fine. Regards, -- Nicolas Mailhot signature.asc Description: Ceci est une partie de message numériquement signée
[discuss] Anonymizing documents for QA bug reporting
Hi, I have several complex corp documents which make OO.o go crazy one way or another. I'd like to report the bugs to get them fixed, but OO.o devs will just ignore me without test documents and there's no way I'll post internal company info in the wild. I discovered the hard way creating synthetic test cases is a lot of work and usually fruitless as many failures depend on multiple factors in the original documents difficult to reproduce without doing the analysis myself (which I don't have the time of the knowledge to do properly). Anonymising text is not too difficult (regexp search and replace) but what kills me is images and variable/reference names. Is there a way to take an OO.o doc, get all letters replaced with X or x, metadata stripped, embedded images replaced by blanks with the same sizes, and every other names (variables, bookmarks, fields, references, color/style names) anonymized? As most bugs happen on complex documents, most complex documents are created in corp-space and corporations don't like disseminating internal info for debugging purposes I suppose I'm far from the only one with knowledge of bugs but no way to report them. Regards, -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OpenOffice.org virus proved in concept
Le lundi 05 juin 2006 à 16:00 +0200, Mathias Bauer a écrit : If you are talking about MS Office: IIRC current versions of it treat macros the same way as OOo so that by default no macro gets executed without explicit user permission. I assume that the higher default security level of MSOffice is the reason why macro viruses are much less important nowadays. However OO.o folks seems enamoured with macros, and having users open documents-with-macros to do basic stuff is hardly going to foster a culture where users are careful about macro warnings. -- Nicolas Mailhot
RE: [discuss] Custom shapes documentation?
Le lundi 29 mai 2006 à 07:46 +0200, Tomas Lanczos a écrit : From: André Wyrwa [mailto:[EMAIL PROTECTED] This is more a problem Of Fonts than artwork.. try this for free http://www.chemsoc.org/networks/learnnet/RSCfont.htm I'm aware of that font and it surely helps, but i just don't think it is a fully sufficient solution. Definitely not, esp. if You are concerned in organic chemistry. If the symbols you need have an official unicode codepoint (or an officious generally-accepted one) you can work with a dynamic project like dejavu (http://dejavu.sourceforge.net/) to help create the font you need. What's different with RSCfont ? 1. it's a work in progress - all glyphs are not drawn yet :( 2. it's a work in progress - there is a team working on it so you can ask them for glyphs they've not prioritized yet or even argue for changes in existing ones :) 3. it's a FOSS project - you can do the work yourself, or have other members of the group you represent help out. On a font project it's pretty easy to assign glyphs to different persons and efforts snowball fast :) Moreover the tools used are free (beer and freedom) so you don't have to shell a fat sum for a commercial tool just to draw a few glyphs. 4. it has very clean licensing - the result could be bundled with OOo or Linux distributions, so you wouldn't even have to download it separately :) 5. it has a fast release rate - every month new glyphs and fixed glyphs are available ;) -- Nicolas Mailhot
Re: [discuss] Install of 1.1.5
Le samedi 27 mai 2006 à 09:11 -0700, Carl Shewmaker a écrit : The disk I installed some time ago has the notation on its face that it is open linux 2.2 Carl, Your linux version is very old (in Linux terms). Plus its manufacturer does not exist as a Linux vendor anymore, as its management decided to sink a lot of money into a foolish lawsuit instead of investing in the tech which made them IPO-rich. Usually it is possible to install new Linux components alongside old ones on a Linux system, unfortunately for you glibc is one of the core components of a linux system so trying to touch it is almost certain to break something else. It's probably *much* safer to install a more modern Linux version instead. Otherwise you can try to build OO.o from sources, which assuming it succeeds (not a sure bet with your hardware) will result in a version linked against your old glibc version. If you're not used to this process I honestly think you should upgrade the system instead (but if you want to go sown this route you'll find some help on [EMAIL PROTECTED]) -- Nicolas Mailhot
Re: [discuss] Surprised this hasn't been on here already but.... SUN HAS OPEN SOURCED JAVA
Le mercredi 17 mai 2006 à 12:37 -0400, Chad Smith a écrit : Will this break down the barriers of the ultra-fantanic fringe free software zealots now? The ultra-fantanic fringe free software zealots have toiled for years to make java on linux work in spite of all the hindrances (licensing, etc) Sun imposed on them. (I personally invested several years of my work in this work) gcj+classpath only exists today because of Sun efforts not to have java-on-linux work. Now it's reaching production level nobody will have a change of faith and grovel before Sun (whoever drafted the new license managed to put quite a lot of excessive terms in it) Now Chad, I don't know how much efforts you've invested in OO.o in the past years, but if MS corrected today one of the small things that make you look at OO.o in the first place, would you declare Office was the best thing since sliced bread ? So in short that's too little, too late -- Nicolas Mailhot
Re: [discuss] Surprised this hasn't been on here already but.... SUN HAS OPEN SOURCED JAVA
Le mercredi 17 mai 2006 à 15:14 -0400, Chad Smith a écrit : On 5/17/06, Daniel Carrera [EMAIL PROTECTED] wrote: Nicolas Mailhot wrote: Now Chad, I don't know how much efforts you've invested in OO.o in the past years, but if MS corrected today one of the small things that make you look at OO.o in the first place, would you declare Office was the best thing since sliced bread ? Knowing Chad, he probably would :) It would take 2 things for me to say that. Not just one. And they are 2 big things - not small. Well Sun hasn't done its two big things for Java. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Surprised this hasn't been on here already but.... SUN HAS relaxed a little bit more its JAVA licensing
Le mercredi 17 mai 2006 à 15:11 -0400, Chad Smith a écrit : Now, Sun has finally bent over backwards and put it under a free enough licence, and you're still not happy? More exactly - I don't care. The time for somewhat free was years ago before a fully free bunch of code had been rewritten. I stopped worrying about doing Java on Sun terms more than a year ago when it become clear gcj would mature long before Sun would resign itself to fix its licensing (they passed a milestone today - only about two more years of proscratinating before they remove the last excessive terms from their license) Now I don't think anyone on this list has any hope left of convincing you of anything, so I'll ignore the rest of your usual perceptive and well-researched analysis. -- Nicolas Mailhot
Re: [discuss] Re: Funding for Evolution Win32 Installer
Le mardi 02 mai 2006 à 09:24 -0500, Rod Engelsman a écrit : End users see the blinking lights and developers see the actual processes. That is why we haven't come and will never come to an understandment. However this is where the Marketing project need to step forward since is the bridge for translating the message to end users. I think this is what they ought to be doing and come with a solution once and for all. Once said that this is the discuss list where this discussions happen everyday without lookng back. It's going to take more than marketing. That's a M$ tactic. It's going to take a serious re-examination of the processes themselves -- development, management, and decision-making. Because it's either an industry, in which case you have to listen to and satisfy consumer demand, or it's a hobby and you're just playing with yourself. Open-source is an industry when there are people paid to participate in the process, including people paid to listen to user tantrums. Open-source is a hobby when people contribute gratis pro deo and have little time and inclinaison to do the same kind of user knowtowing they do at work. When you buy StarOffice, or Red Hat Entreprise Linux, you do not get the same service than when you download OpenOffice.org or Fedora Linux for nothing. Nevertheless they are essentially the same technical FOSS products. The main difference is only suits paid to listen to consumers and bark yes sir at the right time no matter how they are addressed. Current western societies have little patience for politeness. You pay for a product, and buy the right to yell at the call center (customer is king and such crapola. Difficult to address one another as decent persons in this ideological context) However if you think any normally constituted human being is ready to do call center duty for free (satisfy the consumer demand as you euphimisticaly write it) particularly on FOSS mailing lists where the average technical level and income is light-years from call-center level, you are sadly mistaken. -- Nicolas Mailhot
Re: [discuss] Re: Mail Client
Le samedi 29 avril 2006 à 18:29 -0500, Rod Engelsman a écrit : Having said that, though, I disagree with the characterization that this would be creating this whole thing from scratch. One of the beauties of OOo is the code reuse, and a whole lot of the pieces to a PIM already exist in the form of useful APIs, particularly if the thing is built around HSQLDB. However, there are many forms of code reuse. One form is the one which has been suggested in this thread, ie improve bridges to existing external apps to provide integration without duplication. Another is to take a big lump of external code (it's FOSS after all), copy it in the OO.o tree, and start modifying it from there. The second option has the lowest initial costs, and is somehow traditional in the proprietary closed software world (since everything comes with a price tag, and if you don't ship the code you paid for you can not point your users to somewhere they can get it). And after all you have three-year windows cycles, so why bother updating it in the meanwhile. However there are *many* examples in the FOSS world that show the second option is self defeating, since fixes are not propagated from one copy of the code to another (the copy option was taken to avoid coordination costs after all), so you end up with many instances of the same code all broken in different ways, since every project will have fixed different things and made different mistakes. Usually at one point one of the projects has to decide its copy will go (and a lot of its fixes lost), or it will just NOT FIX some things since it has diverged too much. (oh yes and the meanwhile you have users screaming their pet boog is fixed in one of the other code copies, that your app is eating too much memory since it's unable to take advantage of the other different copies of the code already in memory, etc) An awful lot of the work in OO.o was to try to use external components unchanged, and drop the rotten internal instances OO.o 1 used (this is why Linux and WinXP widgets look native now for example). And this work is far from finished (unix printing...) -- Nicolas Mailhot
Re: [discuss] Re: Mail Client
Le dimanche 30 avril 2006 à 10:08 -0500, Rod Engelsman a écrit : All I'm saying is that a lot of the pieces for this thing already exist in the OOo code base. In fact, you could prototype a fair amount of this thing right now just using macros. Heck, OOo even already has half of an email client; it can send emails directly without calling an external MUA for email-merge. So it wouldn't be trivial, but it wouldn't be anything like starting completely from scratch to create an application. There are worlds of difference between being able to send a few mails (in your own semi-broken syntax, provided the MTA does not throw some exotic auth at you) and having a full-featured pim. Nowadays a good PIM requires : - being able to manage all the kinds of mail auth which exist (unlike the sending bit, receive auth is always mandatory) - have a good HTML engine (you do want to be able to read mail other people sent you, right ?) - have a robust read/write LDAP backend - have a robust read/write webcal backend - signing/crypting support (x500 and PGP) - spam/phishing filtering - incoming mail filters - smart quote euristics - IM bridges - attachement handling (no you can't just pass them to the OS, you have to check they're trusted before) - read/write support of common mail store backends (mailbox, maildir, pst...) - searching - groupware sharing functions etc Any shell script can send mails, that does not make them half a PIM. Sending is *easy* -- Nicolas Mailhot
Re: [discuss] Re: Mail Client
Le dimanche 30 avril 2006 à 17:34 +0200, Nicolas Mailhot a écrit : Nowadays a good PIM requires : ... Also a big part of what Outlook/Notes do happens on the server-side so you need both to learn to talk to exchange/domino (to allow stealth / initial deployments) and provide a replacement server part (to allow pure FOSS deployments, since it's not real useful to provide a notes/outlook replacement if you still have to pay MS/IBM for exchange or domino). This BTW is where evolution is lacking the most right now. -- Nicolas Mailhot
Re: [discuss] Re: Mail Client
Le dimanche 30 avril 2006 à 11:14 -0500, Rod Engelsman a écrit : Then all hope is lost. Can any PIM measure up to all that? evo is mostly there, as is probably kmail. (speaking of the linux version, didn't try the win32 port) The moz familly of MUAs has a lot of the functions, but is badly needing some polishing. My point was there is a lot of infrastructure under a PIM gui, and existing projects despite their faults have implemented a big part of this infrastructure, so dumping them to start anew because surely a PIM can't be so difficult to create is quite foolish. A simple MUA is not too difficult A complete PIM (as defined by all the people who complain thunderbird is not complete enough for them) is something else entirely. -- Nicolas Mailhot
Re: [discuss] Re: Mail Client
Le dimanche 30 avril 2006 à 11:14 -0500, Rod Engelsman a écrit : I'm just really *tired* of waiting on Evolution. Also in case anyone's interested Red Hat is currently hiring a developer to work on evolution (fix the bugs its users report and interface with the novell team). He won't work on the win32 port of course but will improve the common core. -- Nicolas Mailhot
Re: [discuss] Re: Mail Client
Le samedi 29 avril 2006 à 14:31 +0200, Cor Nouws a écrit : Nicolas Mailhot wrote: Because in the FOSS world either you can contribute some work (developping, documentation, whatever) and you have some standing, or you don't and are a nobody (and the amount of screeching on ML and forums won't change that) I think that is (or was) good practice in projects from techies for techies. For end user software, with high non-tech-user-demands, of which OOo is an excellent example, I think it is better to find a different approach. I'm sure a lot of people here will be interested if you can point them to any software project that thrived on ML contributions (as opposed to money contributions, as in the commercial software world, or code contribution, as in the FOSS world) Just because thunderbird and OO.o are free (money) to use does not mean they benefit from spontaneous generation. It takes hard work to create complex works of software and this work is paid for one way or another (pizzaware in the Samba case). You're of course free to make suggestions, just as the people who actually do the hard work are free to ignore them. What you can't do unless you contribute something more valuable is make demands or complain no one heeds you. Requiring the creation of an outlook substitute and getting offended no one volunteers is as ridiculous as asking for a pony on a ML and actually expect for it to materialise (and actually the pony would be easier to pull of than the outlook bit) -- Nicolas Mailhot
Re: [discuss] Re: OpenOffice.org 2.0.2 Is Here
Le Ven 10 mars 2006 05:11, Chad Smith a écrit : Of course OOo could run on Mac OS9 if anybody would develop a port for it. An early OOo predecessor, StarOffice 3, had a MAC version (though I'm don't remember if it was sold or not). That was roughly ten years ago and so I have no doubt that a MAC OS9 version of OOo would be possible if anybody had enough interest for it and created a port for it. You can always port a piece of software to a limited environment by reimplementing the missing bits of the environment inside your app. The problem is: 1. it's more work than porting to an environment which already provides what you need 2. your missing bits reimplementation is necessarily less rich than the ones provided natively by other environments (since the development costs are not shared with other users) 3. if you're not careful, the limitations of your missing bits reimplementation are quickly carried over to the other ports -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Fr: Bug sur le bonton KP_DEL et le point (.) dans openoffice
Le mardi 07 mars 2006 à 10:53 -0800, Paul Douglas Franklin a écrit : Sam, Bonjour, je ne parle pas le francais, mais je le lis un peu. I would suspect that this has to do with the European use of commas as decimal points and the fact that the numeric keypad is usually used for numeric entry rather than for typing sentences. Just my suspicion. And it would probably be better if so to take it up with others who use AZERTY on a regular basis so you can debate intelligently exactly what needs to happen. What needs to happen is AZERTY being retired in favour of a modern layout not based on typewriter limitations (like Canada did). Unfortunately, that's not on the radar (for those who care AZERTY sucks in many ways, including access to ., which means even if numbers use , in France you can't put it on the numeric pad) As for OO.o choosing to ignore the OS view of the keyboard layout... Can't say I'm surprised ... Can't say I'm impressed either I hope someday all the legacy StarOffice garbage where OO.o tries to reinvent the wheel is killed for good (it's real blocking right now under free OSes where problems *are* being fixed only to find out the fixes can not propagate to OO.o because someone decided to implement a workaround sometime in the past) -- Nicolas Mailhot
Re: [discuss] Why no Outline support in write?
Le dimanche 05 mars 2006 à 20:59 +0100, Cor Nouws a écrit : I'm pretty sure for most people the extra time for switching between the Navigator and the document is not an issue, even more when you look at the advantages, such as the possibillity to reach all elements of your documents, incl. tables, pictures. That must be valuable as well, isn't it. I do not say that an outline view could not offer some extra, but looking to my experience as professional office-user, and as consultant for both Ms and OpenOffice, I can not give it the weight you do. Well, you know, I'm not part of your most people and I thoroughly hate the navigator : 1. popups suck 2. thumbnail-sized popups suck more 3. thumbnail-sized popups with buttons that do not adapt to the UI size like the rest of the suite suck even more The navigator is not bad when you limit its use to navigation As an outline substitute, it's sorely lacking (hint: people use outline view to get WYSIWYG and other UI annoyances out of the way. It's great to to simple text using the whole screen. The navigator is the complete opposite of this use case, even if it seems to be close from a functionnal view) Regards, -- Nicolas Mailhot
Re: [discuss] Web Office Suite: best of breed products
Daniel, Modern computers have gotten very good at generating documents. So good in fact current office workers are drowning in them, trying to set up decent workflows in the fat station world windows inflicted on us is not fun anymore (when networking was poor at least people finished documents instead of sending them to everyone as soon as they add a new paragraph). Why do you think google desktop search is so popular ? Intranet web app means you only need to coordinate a few servers instead of worrying about every single computer on the network. You can use nas, ldap, etc easily. In the old thin client thin client talked to a big mainframe which centralised processing. Then everything was broken up to do client-side processing. Now we're going back to server-side, except the servers are not big mainframes anymore but lots of small servers talking to one another. The only question is if we're moving to servers glued to clients via proprietary tech like sharepoint or to a pure Internet-like HTTP model. (consumer media hubs/wifi hubs... work the same way BTW. People are so sick of setting up fat stations they buy what's actually small home servers to offload fat client maintenance pains) Regards, -- Nicolas Mailhot
Re: [discuss] Email
Le Mar 7 février 2006 10:10, C Cichocki a écrit : Correct me if I am wrong but I have not yet found and open source E-mail client that offer anywhere near the same level of functionality. Then you should understand why creating yet another incomplete MUA is more stupid than trying to complete the existing ones. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Suggestion
Le vendredi 03 février 2006 à 20:47 -0600, Alexandro a écrit : this list is not the best to suggest this. Before everyhting garamond is not a freely licensed font so we can't ship it with our product. AFAIK However OO.o could consider replacing Vera with dejavu, as vera is not really maintained nowadays -- Nicolas Mailhot
Re: [discuss] Re: Sooner or Later
Roger Markus a écrit : It is reported that the US Department of Homeland Security is spending $1.24 million to hunt for security bugs in open-source software From a spin standpoint, you have to wonder why the government is spending $1.24 million to hunt for security bugs in open-source software, Because it's OSS so the source is available and it can pay someone to look at it instead of signing piles of NDAs with numerous closed software vendors to find problems and then lobby for years to get them fixed. It's purely opportunistic, doesn't mean OSS is less safe, just that it can be secured cheaply (guess which software the US Department of Homeland Security will recommend afterwards, the one they got secured or closed products they could never assess) -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Blank fonts
Le Mer 25 janvier 2006 11:47, Trevor Dearham a écrit : Hi I installed Open Office 2.0.1 on my Windows computer and it installed various variations of the Bitstream Vera Sans Bitstream Vera Serif fonts, but all of these font files are blank. - http://dejavu.sf.net/ -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] contributing to ODF (WAS Re: [discuss] Re: discuss Digest 22 Jan 2006 12:57:35 -0000 Issue 2025)
Le mardi 24 janvier 2006 à 20:30 +, Daniel Carrera a écrit : This is not restricted in any way. It sucks for everyone. The solution is to switch to another list manager, and we're planing to do that. We have a new server, and we're planing to use GNU Mailman in the future. A short-term fix would be to get yourself reffed on marc or gmane. Actually that's also a long-term fix because the cross-list functions of these archive aggregators are much superior to mailman's Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Short list with Pro's Cons
Le Ven 20 janvier 2006 12:11, Andrew Brown a écrit : Jeff Causey [EMAIL PROTECTED] wrote in news:43CF9B8C.7050101 @triad.rr.com: Could you give an example of something Word's outliner can do that navigator or the document map cannot do? I'm just trying to get a handle on the differences as I haven't really used any of these tools in my own work (but perhaps I should be). It lets you edit the text in the same window as it is outlined. It lets you show and hide individual paragraphs (in the navigator you can only show or hide all paragraphs at a particular outline level). It has a very useful view where only the first line of every paragraph is shown. It lets you promotoe and demote paragraphs and their subheadings by pushing them around with a mouse than requiring two different mouse clicks. This is less important, but handy if you're used to it. It fills the whole screen with decent font sizes instead of the microscopic view the navigator offers -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Envelope Printing
Peter Hillier-Brook wrote: The number of times we see questions relating to the difficulty of printing envelopes - often compared with the ease of use of other products - suggests that it would be useful to automate the process. A simple, extensible database of printers, holding manufacturers, types and envelope printing position(s), would enable this with no great difficulty and customer satisfaction would be increased out of proportion to the effort involved. If you want to create a printer db I strongly suggest you start by enhancing the existing ones, such as http://www.linuxprinting.org/printer_list.cgi -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Cert report on operating system vulenablities...
Le vendredi 06 janvier 2006 à 21:54 -0500, Chad Smith a écrit : http://www.us-cert.gov/cas/bulletins/SB2005.html#top This bulletin provides a year-end summary of software vulnerabilities that were identified between January 2005 and December 2005. The information is presented only as a index with links to the US-CERT Cyber Security Bulletin the information was published in. There were 5198 reported vulnerabilities: 812 Windows operating system vulnerabilities; 2328 Unix/Linux operating vulnerabilities; and 2058 Multiple operating system vulnerabilities. Still think Windows is more buggy and unsafe than Linux? In case you haven't noticed, on one side you have windows (two main branches 95 and NT) and on the other all the Linux/Unixes (Linux, FreeBSD, NetBSD, OpenBSD, Solaris, AIX, Tru64, Irix, Unixware, OpenServer, Darwin/OS X, probably cygwin on windows too, etc) So the comparison is not exactly fair Come back when you've combed the 5198 vulns, removed duplicates and separated specific OS versions so you can compare a single windows version to a single Linux version. Also 1. vulns are not graded, 2. if I remember well MS tend to aggregate a score of minor problems in a single report while Linux is more one problem = one report But anyway the proof in the pudding, ask anyone who ran two installs side-by-side for a year which one got the most problems -- Nicolas Mailhot
Re: [discuss] Cert report on operating system vulenablities...
Le samedi 07 janvier 2006 à 13:05 +0100, Giuseppe Bilotta a écrit : Saturday, January 7, 2006 Lars D. Noodén wrote: Some class action suits might get MS to clean up its act somewhat, but at this point it'd be foolish to expect any change in their quality or business model. Won't work. The EULA expressely exempts MS from any damage caused by bugs in their programs. If you installed them, you have accepted the EULA. But would all the provisions of the EULA stand in court ? IANAL but I seem to remember european law at least requires a basic level of service, so you can put all the exceptions you want in fine print in the contract nobody reads, they can't preempt the general provisions. I doubt an EULA which stated you accept the installation of malware $foo on your system and I won't be liable for anything would have any legal value. If someone wanted to make a MS-like EULA stick he would have to convince the legal system the EULA provisions are consistent with what a basic customer can expect, which would be very difficult to do. The law does not like it at all when you say something to your customer (when you buy MS you got support, when you buy FOSS who can you sue?) and write something else in legal documents. All the ebayers that sell pictures of stuff with the picture part carefully stated in fine print are in for a very nasty surprise if someone ever sues them. In other words : EULAs are a modern form of scam, I doubt the Law will like them any better than the previous forms. -- Nicolas Mailhot
Re: [discuss] openDoc
On Mer 21 décembre 2005 00:33, Paul wrote: Ah - docBook... Not too sure what should / should not be contained in this format. I've included the list for possible responses from others. Docbook is very high-level and separates content from presentation very thoroughly (in fact the content party is rigidly specified, the presentation part not. Which means the presentation layer can change whenever you want without needing to rewrite documents) To work well with docbook OO.o would need to have much better styling support than now. And even then, you'd probably loose most of the eye-candy when saving Docbook is a very nice format - it forces people to structure documents instead of painting them in bold and italic. Of course WYSIWYG people hate it. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Official request for rectification of Mr. Andrew Brown's article
On Lun 12 décembre 2005 21:32, M. Fioretti wrote: Maybe, in the case of corporate funded projects (oo.o and similar) the paid developers could be forced by their employer to directly spend time *talking* with end users in human ways (= not issuezilla and similar). Honestly, in case of a traditional closed software project management would probably try to limit these interactions as most as possible. The conventionnal view is : 1. developper should be coding instead of interracting with users 2. features/enhancement/roadmaps should be approved by marketing (who prefers interviewing a few highly-placed executives in well-publicised events rather than sifting through thousands of user reports) 3. average user should be processed by low-paid call-centers people, using scripted answers designed to minimize call length. Of course the filter in 2. is highly selective, so 1. never gets the big picture and 3. never gets good service. The way OO.o treats its users is much closer to traditionnal closed software practices than FOSS standards. FOSS often works better because users do not feel abused, so they try to give better reports, and user-developper interaction is direct, which removes the distorting effects of going through marketing (marketing will try to push big customers requests first, forgetting that big customers do not provide good feedback - they're paying you so much you're supposed to identify their problems all by yourself) I've worked in a software house where suggestions of the test team (paid to drone through the application all week long) were ignored for the creative insights of a few high-level marketoids, who never bothered to actually use the software - when some area needed work they just had some intern manipulate it for them instead of marking the area for fixing. They did request some eye-candy no one ever found an actual use for though (but it looked good on slides) -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Official request for rectification of Mr. Andrew Brown's article
On Dim 11 décembre 2005 11:55, M. Fioretti wrote: On Sun, Dec 11, 2005 11:11:00 AM +0100, Gianluca Turconi ([EMAIL PROTECTED]) wrote: Same thing for Mozilla or Gnome, I think. Yes, of course the same problems in any big project. OO.o is competing with all the other foss projects for volunteers. That means that people who could contribute small fixes, detailled bug reports/testing (which costs real money if you don't have a good beta tester program), will do so for the projects who bother to answer them quickly. And you may dismiss bug reports as whining but that's the stuff that avoids you sinking years of development in features no one's interested in (for example, the old staroffice desktop) And sure you don't owe anything to these people, they owe you since the work of writing the actual program is much higher than reporting a few warts, but they owe many other projects not just yours and it's only human they'll tend to contribute to the friendlier projects. That is, the projects where you actually see developpers on the public lists, and can give them your opinion directly from time to time. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Official request for rectification of Mr. Andrew Brown's article
Gianluca Turconi wrote: Uhm... I have to point out a thing: I'm a very pragmatic man and I have had a law education. Thus, as I've written to Marco, clues are not evidences for me. They can be used in discussions like these ones, but they have not any real validity when we want to confirm an assertion like: The OpenOffice project vividly illustrates the limitations of open source as a way of producing software The OpenOffice project vividly illustrates how free software is more than licensing changes. Free software is about component reuse, not big monolithic apps (ie exactly what OO.o is not for historical reasons) Free software is about submitting changes to the other FOSS projects you use, instead of complaining they're incomplete and starting your own new codebase (chandler and other persistent attempts to recreate an OO.o mail client instead of interfacing with existing projects show the OO.o community still does not get this part) Free software is about releasing early, releasing often (how long did OO.o 2 take to mature ?) Free software is about nurturing contributions by accepting other people changes, even if they are low on your roadmap or the initial effort to merge them is higher than doing your own thing (tense relations between OO.o and Ximian OO.o) Free software is about listening more to user input than a personal roadmap, and fixing the bugs users actually complain about (no active follow-up on issuezilla entries) ... And the list goes on. Free software was never about other people magically fixing exactly the parts of your software you wanted them to, it's more about accepting and helping change you didn't plan for. So far OO.o has been open-sourced but Sun has not really accepted the other bits. It's striking that almost every single set of slides on : http://kegel.com/osdl/da05.html complains about OO.o not really listening to input, and following its own private roadmap. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Email vital for Desktop Linux adoption, prime role available for OOo
On Mer 7 décembre 2005 15:09, Daniel Carrera wrote: Joerg Barfurth wrote: Take a look at Tools-Options-Load/Save-General. There is an option 'optimize XML for size'. This option defaults to 'optimize' and iirc it was introduced in an early effort to make the file load process faster. I know about that option. I always turn it off because I like being able to read the XML. And it doesn't seem to significantly affect the file size or application speed for the documents I use (50-pages at most). This is a standard XML generator option. It's used because inserting whitespace costs some processing (to do pretty indenting you have to count how many levels you are inside the structure), and increases uncompressed file size a bit. So most XML generators (which do not produce XML intended for humans, nor compress them aftewards) don't bother with whitespace by default. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Email vital for Desktop Linux adoption, prime role available for OOo
Randomthots wrote: So if that all is true, then what we probably really have going on here is that OOo processes the file inefficiently, and in a fashion that makes heavy demands on memory, and that inefficiency is only exacerbated by the file size, which *is* a direct mathematical consequence of the verbosity of the tags. So what ? Nobody said it wasn't a factor. What people said it wasn't THE factor. When you increase the cell number you're not only increasing the number of bytes (compressed or not) OO.o has to process. There's many other ways you're also putting pressure on the system, most of them probably scaling worse than system memory. Is that so difficult to understand ? -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Email vital for Desktop Linux adoption, prime role available for OOo
Randomthots wrote: So you've proven that xml is inefficient for storing highly structured data. XML is not designed to be efficient. XML is an interchange format, and was designed first and foremost for interchange robustness : 1. it's generic and extensible 2. an xml file can be validated against a grammar (and the grammar language can be used to place very strong constraints on data) 3. it is human-readable 4. it does not optimize away important stuff like the encoding used 5. etc Each robustness layer comes at a cost, but the HTML wars (and fast obsolescence of binary formats, etc) proved to a lot of people strong format validation was cheaper than having to support all the competing, morphing, short-lived and mutually incompatible efficient formats of the day. If you want efficiency, you should use a database, not a spreadsheet. Databases operate at the other end of the generic/efficient spectrum. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Re: Re: Re: Email vital for Desktop Linux adoption, prime role available for OOo
Andrew Brown wrote: Daniel Carrera [EMAIL PROTECTED] wrote in news:4395B978.50606 @zmsl.com: Not all organized crime is violent. Anti-trust violations /are/ a crime and they are also organized. I think you're blurring an essential distinction. Organised crime does not mean crime committed by organisations. It means crime committed by organisation whose core businesses are illegal -- drugs, prostitution, extortion, gambling -- where they operate. No, organized crime means exactly that - crime committed/prepared in an organized manner (ie not impulse crime, or individual crime) The organization can be created specifically for the crime or exist beforehand for other objectives. What the law recognizes is people working together can do a lot more harm than people working separately on their own, so any sort of organization will also lead to stronger punishment (also states do not like hostile organizations - they're more a threat to them than individuals) In this context company memos ordering criminal actions are indeed organized crime (however I doubt anti-trust violations are a criminal charge, looks more like a civil charge to me) -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: Email vital for Desktop Linux adoption, prime role available for OOo
Randomthots wrote: Remember, this was a big file. 63,260 rows by 7 columns. That's 442,820 instances of the 80 bytes of taggage surrounding each cell (35 MB, total) plus the tags at the start of each row (times 63,260) plus all the header information. Apparently with 256 MB RAM I simply ran out of room loading the ods which didn't happen with the csv (or the xls). And you know what ? Your RAM depletion had probably little to do about tag length, and a lot about OO.o trying to build its XML tree in RAM. -- Nicolas Mailhot - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Re: a more complete office suite
Le lundi 21 novembre 2005 à 00:04 +0100, Henrik Sundberg a écrit : How about the anti spam Haiku? http://www.oblomovka.com/writing/habeas:_the_antispam_haiku.php3 Like SPF it is very popular with spammers. Micropayements rely on spammers accepting to pay and not subverting someone else's account. The Haikus rely on spammers being willing to respect someone else's copyright Their only failure is to postulate spammers are law-abiding (slightly confused) businessmen, while they are uber-capitalist scum which care about little expect making some quick money (another recent example of the right to make a profit at all costs is being demonstrated by Sony these days) And yes I'm a crypto communist and I keep my mouth-knife on hand. -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le jeudi 17 novembre 2005 à 11:51 -0600, Randomthots a écrit : Q: Why is spam usually in html format? A1. Because advertisers like flashy colours. With flashy effects you don't have to bother about meaningful messages and correct grammar. A2. Because if spammers understood tech or ethics they wouldn't be spamming in the first place. A3. Because one can use 1×1 pixel images embedded in the html to detect which message is actually read, and thus validate address lists A4. Because in HTML you can cloak links and display adresses different from the ones you're actually linking to A5. Because the HTML format is so convoluted you have many ways to hide your spam content from spam filters, which can not integrate a full HTML engine to detect what the user will actually see displayed. So it's a filtering pass-through A6. because spammers don't care about standards or conventions, and abuse them routinely -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le jeudi 17 novembre 2005 à 14:11 -0500, Chad Smith a écrit : That's why websites aren't just plain text. Because pictures, links, formated text, alignment... All these things aid communication. Remind me to make you discover Google someday. It's a little-known site crippled by lack of communication aids. Should take a lesson from altavista. Or you could spend some of your time reading professional typography guides (even going inside a real library !). 99,99% of HTML capabilities are filed under amateurish schoolboy effects which hinder communication there. -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Randomthots wrote: Now consider that ODF is a much richer format than HTML. And being similar to HTML, there is no technical reason (that I see, anyway) that the format couldn't be adapted to eventually replace HTML. HTML is already TOO complex for mail. That's why it's rejected by so many people. Didn't you read what I wrote last day ? Rich mail acceptance requires a simplified SUBSET of HTML/XHTML, not a SUPERSET like ODF. I shudder a the number of cycles needed to filter a mailing list if its default format changes to ODF. -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le lundi 14 novembre 2005 à 16:58 -0500, Chad Smith a écrit : On 11/14/05, Nicolas Mailhot [EMAIL PROTECTED] wrote: HTML is already TOO complex for mail. That's why it's rejected by so many people. Didn't you read what I wrote last day ? Rich mail acceptance requires a simplified SUBSET of HTML/XHTML, not a SUPERSET like ODF. I shudder a the number of cycles needed to filter a mailing list if its default format changes to ODF. Nobody cares if you want to filter your email to exclude HTML. That's your right, and no one is considering, suggesting, implying, or saying that we should take that right away from you. No one is suggesting that we force you to send email in any form other than the one you choose. And no one is implying that we should switch the mailing lists over to HTML, ODF, XML, or PDFs. That's not what I wrote. Blacklisting a file type is easy and fast. What I wrote is if people want a rich mail format that is accepted by mailing lists, mailing list filters (the stuff that runs on SERVERS) need to be able to check message sanity in as little cycles as possible. Which is about impossible with current HTML abuses, and would be even worse with ODF. Though it would certainly be possible to specify a message format better than plain text with good filtering properties which could accomplish 99% of what normal people really use in HTML mail today. There is a reason why entreprise mail clients only run on highly protected networks you know - they don't have the feature/sanity balance it would take to connect unprotected to the internet. And getting there do mean dropping the features which cost too much to secure for too little gain. Unless you advocate big-corps-only-OO.o -- Nicolas Mailhot
Re: [discuss] Re: Re: a more complete office suite
Le mardi 15 novembre 2005 à 08:01 +1000, Sam Stainsby a écrit : On Mon, 14 Nov 2005 02:46:57 -0500, Lars D. Noodén wrote: On Mon, 14 Nov 2005, Jonathon Blake wrote: Just what functionality does MSO + Outlook offer, that can not be replicated by using OOo + FireFox + ThunderBird + SunBird + the appropriate templates? [...] +1 Example 1: The ability of users, using their email client, to set up an appointment by taking into account the potential participants' free/busy times, email the invitation to to the potential participants, and have them accept/decline with a click of a button in their email/calendaring client, automatically adding that appointment to their calendars. On Microsoft Windows and Linux desktops. This could perfectly be accomplished by linking properly OOo to FireFox + ThunderBird + SunBird -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le lundi 14 novembre 2005 à 18:04 -0600, Randomthots a écrit : Finally, how may cycles does it take to scan a binary attachment for viruses? And what are the consequences if the scan fails to reveal a viral hitchhiker? Scanning for viruses (virus signature check) is way easier than parsing an ODF file to infer what's really displayed at the top of the mail (cf all the spammer HTML tricks to make spam display at the top of the file while stuffing it with nonsense that's hidden from he human reader) -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le vendredi 11 novembre 2005 à 12:21 -0600, Randomthots a écrit : mark wrote: Think about it: If html-mail is associated with spam -- and I will gladly stipulate that there is a statistical correlation -- and if 1) ISPs filter much of that spam as mine does, and if 2) much of the rest is caught by individual e-mail clients, as mine is, and if 3) most people simply delete what does get through all that, as I do, then html-mail is a spectacularly ineffective vector for malware. Spam never was about effectiveness. Spam always was about blanket-bombing and massive waste of ressource. Accepted (by mail admin people) HTML mail will happen when people get together and write and RFC about the XHTML subset one can sanely use in mail clients (ie remove all the dangerous elements built-in XHTML). And then refuse anything except this subset. And it won't ever happen because : 1. the only interested people are Outlook/Notes/WordMail users 2. Outlook/Notes/WordMail output and process non-standard XHTML and writing a spec they'd have to respect is the last thing in the minds of their authors. So even if someone else wrote it they would ignore it. However since you obviously care about HTML mail I invite you to specify an XHTML subset that can not be abused, get it supported by outlook, and come back asking for thunderbird/OO.o support. -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le jeudi 10 novembre 2005 à 13:24 -0800, jrc a écrit : Please discontinue the refrain that 00o attachments to Thunderbird will do the trick. Try that on most mail lists! The attachment is promptly rejected as spam, or is otherwise butchered. Do you really think inline complex HTML will fare any better ? With the current spam levels mailing list admins zap just anything suspicious (as they should) -- Nicolas Mailhot
Re: [discuss] Re: a more complete office suite
Le vendredi 11 novembre 2005 à 01:19 -0600, Randomthots a écrit : mark wrote: The most prevalent means of spreading viruses is through binary attachments to plain-text e-mail messages. Precisely the manner of transmitting complex documents most loudly advocated for by those opposing html-mail. Any half-decent spam filter will treat attachements and core messages the same ways. ie if it's blocked as attachement, it will be blocked as message and the reverse is also true. The problem is not core vs attachements but what you choose to allow. And since ODF HTML allow macros and waste bandwidth, they're legitimate filter targets. Better block some mime types altogether than have your filters perform expensive analysis to check they've not been abused in all the ways they can be. Especially on high-traffic mailing list servers where you have to process a huge number of messages every minute. Regards, -- Nicolas Mailhot
Re: [discuss] Gates memo warns of 'disruptive' changes
Le mercredi 09 novembre 2005 à 20:27 -0500, Alex Janssen a écrit : Chad Smith said the following on 11/09/2005 11:31 AM: Gates memo warns of 'disruptive' changes http://news.zdnet.com/2100-9588_22-5940792.html?tag=nl.e589 In a memo to top company executives, the software giant's chairman ponders the challenges posed by a host of online competitors. It seems MS is more worried about Writely - http://www.writely.com/ - than it is about OpenOffice.org. That's not a slam against OOo, merely a suggestion that a online version of OOo (like, perhaps, the one Google is developing) would be a good idea right about now. I don't think writely.com or windows live or office live will be replacing OOo in my office any time soon. I know that you can speculate that it might, but it won't. Any ASP software offering will face three big hurdles in an entreprise context : - oldish browsers, so can't do modern HTML - security. You can bypass security for a while by using only standard http ports, but I assure you the security team will find out about you soon enough - bandwidth. This is the worst of all. Big corps have fat pipes but they're usually only just as big as they needed to be two years ago, and for an ASP app that means starvation, big latencies (+proxies...) and furious users. (I spent 3 years doing RD + Support for an ASP solution) So ASP is more a home solution today. Generalised broadband helps a lot. In the Office context that won't impact MS revenues directly (lots of home installations are either pirated or bundled with the computer), but could have huge side-effects by teaching people they could use other tools than office to manage their documents. We like having our software run locally and having our data local, not on someones server somewhere in internetland. Just imagine someone you don't know filtering through your company data without your knowledge. It could happen if you give someone else control over your data. This OTOH is not a big problem. People have yet to be educated about data safety (spammers are working on it) any piece of official-looking paper presented by a smiling marketoïd ensuring the data is safe will overcome the objections of the security team. Why do you think the big Mastercard/Visa security breach of last may was possible ? No one tracks sensitive data over time. (and usually people don't even consult their security team when buying ASP. It's out of the entreprise network, so they think they don't have to bother) This is why BTW entreprise security teams won't ever say an ASP solution is unsecure and should not be chosen. They'll make it unattractive by limiting the bandwidth it needs. And then ask for a huge budget to improve internet access to the levels required by the app. Usually it's sufficient either to kill the project, or get the procurement manager in deep denial saying the network is good enough and users should just cope with the latencies (a great recipe to get an app hated by everyone). Regards, -- Nicolas Mailhot
Re: [discuss] Re: The .odt file format
Le vendredi 04 novembre 2005 à 14:13 -0600, Randomthots a écrit : Daniel Carrera wrote: Randomthots wrote: This is why I question the philosophy of keeping the wall of separation between office productivity apps and communication tools, like browsers and e-mail clients that some on this list seem so adamant about. It would be stupid for OOo to try to do everything. It has to make a decision about what it's trying to be, and stick to that. Sure. But is that decision carved in stone? Regardless of customer demand or desire? BTW, what exactly is the it making this decision? Not the program itself, I assume. It's people, right now mostly people working for Sun, and people have been known to change their minds when appropriate. Just because you're one user does not mean every potential user/customer shares your wishes. Lots of people would put DTP or CAD before mail (plenty of good mail clients already, remaining problems server-side not client-side). And anyway you can't sanitize/optimize code while integrating boatloads of new features. Next release focus is optimizing so don't expect whole new components in this one. -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le dimanche 30 octobre 2005 à 09:13 +0100, Giuseppe Bilotta a écrit : As I mentioned in one of the parts of my mail that you snipped, I have nothing against language selection in style. Why? Because language is a property of the text. True, it's not a property with an immediate visual feedback, but it can influence typesetting (by e.g. changing the hyphenation points and thus the overall formatting of the paragraph). If language can influence typesetting then let's have it influence typesetting, not the other way round like now. ie permit conditional styling which I think it's clear by now is the only expressed need for style - language interactions. ie make the language field in styles mean if the text is in this language not set the text to this language and have OO.o switch between alternatives automatically (when this filed is set, allow creation of sibling styles for other languages and define one default style if the language condition is not met) I am not sure what you mean by language conditionals, OTOH. Something like: if the language is Italian, format this way, if the language is not format this other way? If this is it, the idea doesn't appeal to me very much, honestly. With free cascading styles you'd have a better workaround for languages than now, since you'd be able to short-circuit the macro step but it would still be a workaround. Just consider what happens if someone changes the language in your style instead of just changing the formatting attributes - instant content loss Why would someone change the language in any of my styles? Because you can (usual stupid reason : if you expose a control to users don't be surprised they'll use it). And you can't do it sanely because you don't have the affected text on-screen and can not check you're doing the right thing. Honestly instead of continuing to avoid the issue and devise better workarounds than the current workaround please all of you forget the current implementation and focus on the two needs that have emerged : 1. set the language of the text while typing, with possibility to change later the langage of a selected part of the document if it has wrongly been entered (later enhancements : sync with input methods, autodetection routines, etc) 2. have language influence typesetting (your words, not mine, but all too true). This need is not limited to character styling, you can imagine adding a small flag before §s for example. For me: 1. clearly requires what you have been called hard-formatting in this thread (it's not formatting, but it's certainly hard ie not mutable) 2. calls for conditional formatting in my mind. If you disagree here, please argue starting from the user need not the current implementation. You can arrive to the styles need to set language conclusion if you want to but please show how it will actually help users to have it this way. I posit anything else than what I propose will be suboptimal, as my proposal is a direct mapping of what users been asking for. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le dimanche 30 octobre 2005 à 09:23 +0100, Giuseppe Bilotta a écrit : Anyway, editing styles does not involve any form of search/replace through the document, since styles, in a way, a re just pointers; so when a style is changed, the only thing that gets changed is the area that contains the style definition: all the pointers to that area remain unchanged. This is why they're wrong for langage, as you never want to change the language attribute of some text without having it on-screen at the time. -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le dimanche 30 octobre 2005 à 17:14 +0100, Henrik Sundberg a écrit : I've read this thread with interest. I had no opinion at all from the beginning. I think the arguments of Giuseppe are more convincing than those of Nicolas. I don't think the presentation gets mixed with the contents by adding language as a cascading style. And I don't think any attributes added to the language tags later on will affect the translation at all. Like Giuseppe, you assume attributes are added the the language tag. It is not so. In the current UI, and the UI Giuseppe proposes, language is just one attribute. It will be changed just like bold, font or any other style attribute. I'd have no problems with his proposal if it was indeed only adding on language, if language influenced presentation or any of the many other way this has been expressed in the thread. But the truth is the separation which is expressed in your words and in Giuseppe's does not exist in his proposal. You're both relying on the fact people should be careful. People aren't careful in real life. You have to give them tools that do not permit behaviour you know beforehand is stupid and dangerous. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le dimanche 30 octobre 2005 à 19:46 +0100, Nicolas Mailhot a écrit : Le dimanche 30 octobre 2005 à 19:11 +0100, Giuseppe Bilotta a écrit : And I think the solution I present would solve that kind of problems *too*. Not so sure :( And BTW if I haven't made it clear before I totally agree with your idea that at the character level one should be able to apply as many non-overlapping styles as needed. I just don't believe it's the right solution for the langage attribute. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le dimanche 30 octobre 2005 à 20:44 +0100, Giuseppe Bilotta a écrit : Ah, excellent example ... too bad it shows what I think is a small flaw in your expectations: this kind of featureset is to be found in DTP applications, *not* standard wordprocessing apps. So, if I were you, I wouldn't keep my hopes too high. I've given up long ago on DTP. Office applications are good enough for most people, which means DTP is restricted to a little elite, which in turn drives DTP prices sky-high, which narrows even more the DTP niche. Even printing houses nowadays accept office documents because refusing them would significantly hinder their business. This BTW is one reason you have strict separation of typesetting and translating people in the real word. Translators work on text flows in cheap office suites, typesetters have lots of expensive software to manage illustrations and so on. Though in practical terms, since the text must go back and forth between typesetters and writers/translators during the document lifetime, typesetters are forced to use office formats. If they didn't they'd have to reconvert every time someone needed to add a paragraph somewhere. To me it looks like office suites have killed the whole DTP concept which is now dying a slow depth. Forcing in turn office suites to implement features needed by former DTP users. Including stuff like what we are discussing. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le samedi 29 octobre 2005 à 03:55 +, Andrew Brown a écrit : Nicolas Mailhot [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: The problem is this kind of linking is strictly hierarchical, you have to think beforehand how your styles will be combined, and if you change your mind later (or inherit the document of someone else) the whole style hierarchy must be redone. Sorry to keep banging on here, but I have demonstrated a way around this problem and it is important. Sure. It's a pity you have to do it voa macros though. That's out of the reach of many users. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: Re: Multiple character styles (was: Re: Mixed language text spellchecking question)
Le samedi 29 octobre 2005 à 12:41 +0200, Giuseppe Bilotta a écrit : An obvious remark is that text in a foreign language is in that foreign language, full stop. It's highly dubious that you could have second thoughts (hm, maybe this isn't Russian, maybe this is Japanese) and have such second thoughts consistently across all occurrences of that language. Which means hard formatting like done with the macro is the right thing to do in the langage case *However*, taking your example (different font for Swedish text) is exactly the reason why it should nevertheless be part of an appropriate style, and not be applied manually (or macroly): if halfway through a document to decide, or otherwise need, to set all the foreign text in a different font (or with a different font property, typically in italic), you can of course change the macro, which will work for all the *future* text, but it won't change all the text you already typed in. This is *exactly* what styles were made for. This is an argument for putting language conditionals in styles, not making styles set language like nowadays. I understand what you'd like OO.o to do but langage management is not a valid argument. Free style mixing (with attributes that really belong in styles) is a valid argument. With free cascading styles you'd have a better workaround for languages than now, since you'd be able to short-circuit the macro step but it would still be a workaround. Just consider what happens if someone changes the language in your style instead of just changing the formatting attributes - instant content loss Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: re: Massachussetts registered voters
Le vendredi 28 octobre 2005 à 08:14 +, Andrew Brown a écrit : Shawn K. Quinn [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Microsoft only cares that you keep using their products and giving them your money; they really don't care whether or not you can use a competing product. Of course. How is this supposed to be uniquely wicked? Do linux zealots care whether anyone can use MS products? Of course by inserting zealot here you've answered your own question. Now if you remove the zealot part I'll say they care very much after interoperability. They support multiple non-Linux filesystems, have samba, wine, etc. No one in the industry has gone so far to communicate gracefully with other systems, except perhaps the BSDs (and I doubt BSDs have such a strong commitment, as they have a much more limited focus). So this line is both wrong and pretty offensive to all the people that did this interoperability work. You can't compare Linux to MS in the interoperability field. They're not even close. In fact they're pretty much at opposite ends of the interoperability spectrum. This being said there is a strong feeling in the Linux world nowadays that silently bearing the costs of interoperability is not enough, and pushing for conventions or even standards that would level the field a bit is the right thing to do. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Mixed language text spellchecking question
Le vendredi 28 octobre 2005 à 09:13 +, Jonathon Blake a écrit : Cono wrote: No, you just need ONE extra style for each extra language. Read my previous message. What you recommend in that message works only if the document hs _one_ pragraph style. The moment you need two or more paragraph styles, that hve multi-lingual text in them, you need a chrcter style for each language. [Not to mention paragraph, numbering and maybe even page styles that are language specific.] Not to mention as soon as you have one style that does not follow the artificial conventions needed to manage langages via styles, all hell breaks loose. And you're multiplying the styling charge by n where n is the number of languages in your document (helloo technical notices with 10+ intermingled languages to avoid duplicating schemas) chnge color for on the screen, if you like. That is a good arguement in fvor of using styles. But it has virtually zero applicability on the practical world. This is *not* a good argument for using styles. This use case is something like revision marks, you don't use styles to change the display of revision marks. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Mixed language text spellchecking question
Le vendredi 28 octobre 2005 à 10:27 +, Jonathon Blake a écrit : Nicolas wrote: - and I may be wrong there, but can you apply multiple character styles to the same word Each character in a word can have a different character style. A character may only have one character style and one paragraph style, though. As I suspected. This means if you use character styles for language, you can't use them for anything else without endlessly deriving character styles based on language. Which as Shoshannah wrote is a major PITA, and she's only working with dual language documents. ... If you don't create a very simple style that only specifies language, there is bound to be bad juju interaction with formatting. Create a parallel style for every language. This ends up with a number of styles, but it keeps the formatting straight. [Just don't save your document in RTF.] This is what people are complaining about. That's a step most of them have no use for, and it's incredibly time consuming Also if you go through styles that means users will have to set up what style to apply with what input every time they change documents That is what templates are for. Or just add all 10 000 styles you have created to your default template. Can't. Professional translators for example work on already existing documents which already have a style set (which does not include languages BTW because the original writer cared little about those bits). Usually they do contract work for many different clients which all use different conventions, so if language conventions are not enforced at the tool level that means restarting from zero every time. Nicolas wrote: From a pure UI POW what most users expect is a dropdown control with a language list in the toolbar (like for styles, but strictly limited to language), and a key accel to quickly switch between the languages Andrew Brown wrote: This could surely be cludged around with an addin. Your proposed kludge is fairly simple: i) Duplicate the current cell/paragraph/character style. ii) Change the language to the new language; iii) Save new character style. and iv) Hope that the user remembers that they have already created a character style with the language that they want to use. [If they don't their style sheet will be littered with styles that they created as one shot uses. Search/Replace can't search for character styles, to clean that mess up.] This supposes the original document is properly styled, when you are not the original author just a poor translator you have to work with what people give you. You're not paid to re-do the styling of the whole document just to be able to use OO.o language facilities. Nicolas wrote: but I don't feel we are making any sense to the styling camp. Essentially, the choices are: i) Include language as a style attribute; ii) Include style as a language attribute; iii) Completely separate styles and language, allow something like if(russian) in styles for the few people that need language-based conditional formatting. That's the only justification for language-in-styles nowadays and there's absolutely no reason it must be implemented by having styles set language. Regards, -- Nicolas Mailhot
Re: [discuss] Multiple character styles (was: Re: Mixed language text spellchecking question)
Le vendredi 28 octobre 2005 à 10:41 +, Jonathon Blake a écrit : Giuseppe wrote: you can't have multiple character styles for the same text Is this really? Depends upon what is meant by can't have multiple character styles in the same text. What is meant is select whole sentence and apply italic+variable character style, then select greek word in sentence and set greek language (without loosing the italic+variable styling) Regards, -- Nicolas Mailhot
Re: [discuss] Re: Re: re: Massachussetts registered voters
Le vendredi 28 octobre 2005 à 11:53 -0400, Chad Smith a écrit : On 10/28/05, Ian Lynch [EMAIL PROTECTED] wrote: Also vulnerable to catastrophic loss as in the libraries of Alexandria. Difficult to have a complete back up of all the paper and be sure it won't get destoyed by fire or flood. But it's easy to do that to computers - right? With computers you need multiples copies on several physically different sites and periodic checksum checks. IE live computer data, not something left to a degrading physical support. -- Nicolas Mailhot
Re: [discuss] Multiple character styles (was: Re: Mixed language text spellchecking question)
Le samedi 29 octobre 2005 à 06:57 +1000, Jonathon Coombes a écrit : On Fri, 2005-10-28 at 10:41 +, Jonathon Blake wrote: WordPerfect is based on text streaming, so style effects can be cumulative. OOo is based on objects, so style effects are not cumulative. You may be able to achieve a similar cumulative effect however with the linking of styles. This is like an inheritance of the object and its properties so you define a base character style, then link a new one to that which will add to that style. The problem is this kind of linking is strictly hierarchical, you have to think beforehand how your styles will be combined, and if you change your mind later (or inherit the document of someone else) the whole style hierarchy must be redone. -- Nicolas Mailhot
Re: [discuss] Re: re: Massachussetts registered voters
Le jeudi 27 octobre 2005 à 18:23 +0100, Daniel Carrera a écrit : Robin Laing wrote: I do see Chad side of the argument. There is an ISO standard for date formats but many different formats are still used. Heck I have seen three different formats on one single form. People like to use what they are used to. Well, date formats are not going to severely hinder interoperability. You're being as naïve as Chad there. Business processes depend on exchanging documents containing dates in a standard format. Now that ISO the W3C have finally adopted a single format corporations are spending big money to convert to it (even on legacy systems in maintenance-only mode). Because the current mess is costing them even more money. It will happen before ODF is widely used and even if ODF fails. Home users like Chad do not realise the budgets corporations are ready to extend on standardisation, because even if the sums are pharaonic when you're bigger than a critical mass they pale before the costs of not standardising (and no a format linked to a single provider is not a standard). That's why they've created organisations like OASIS. OASIS is a pretty much a big corporation lobby that tries to beat sense in their software providers. That's why you find Boeing employees in TCs, and why any standard hashed out there will be considered more carefully by corporate buyers than anything created by software editors for their own ends. Regards, -- Nicolas Mailhot
Re: [discuss] Re: Mixed language text spellchecking question
Le jeudi 27 octobre 2005 à 21:10 +0200, cono a écrit : Nicolas Mailhot wrote: Le jeudi 27 octobre 2005 à 14:12 +, Andrew Brown a écrit : This could surely be cludged around with an addin. I know and you know that the underlying mechanism would still be styled, but no one else would :-) If only it was that simple :( If you don't also neuter the UI that enables setting language in styles, you'll have collisions between styling and your new langage control, with users asking why the styles are suddenly changing the language they specified when typing their text. I do agree that a better cludge than the current cludge is possible, but till it's uncludged it'll have cludgy side-effects. I do recognize the idea of Andrew. And as far as I understand it, it won't conflict with the style feature. Sometimes it is like you do want to keep people away of the effort to learn about styles, Nicolas. For me there's no misundertanding about styles and what the language does with it. And so many more things about styles are valuable to know. For ease of work, to prevent format-mess, ... I'm not opposed to styles. Far from it. But I was exposed to the concepts behind styles way before I was exposed to SO/OO.o, so for me OO.o styles are just one implementation of this concept. And I'm able to recognise the shortcomings of this implementation when I meet them. If you get past the styles are cool stage you quickly find ways the current implementation could be enhanced. BTW, and not so unimportant ;-) we've been drifting far far away from the question of the OP: he/she had some troubles with spell checking of different languages in one doc. Because of minunderstanding, or because of a bug? Actually, we've not strayed so far. The user had trouble with spell checking of different languages in one doc because the language implementation in OO.o is utterly alien to him. The enhancements he proposed are made problematic by this very same implementation. If I had to guess OO.o language handling happened this way: 1. marketing person tells developer team they have to handle multiple languages in documents 2. developer team asks if language is some sort of text attribute (people working with human languages go to different universities than people working with computers, so they're not sure) 3. marketing person answers yes of course (he got other things to do) 4. no one does any usability study 5. developer team puts language in the style structure with the other text attributes 6. a user discovers langage in styles enables some sort of langage-based formatting 7. everyone cheers and congratulates one another on the decision to put langage in styles The problem being langage is a text attribute all right but it's an immutable attribute. It's ok to change the styles of bits of text when restructuring a document but langage must pretty much be left alone during these operations (OO.o can't translate text on the fly). So any normal human being not formatted by the way OO.o handles language is confused by the current interface (as any usability study will show). This user was no exception. And sure when you understand the way OO.o does styles you can sort of make it work but you have to fight the tool all the way. It's not behaving the way it should. I spent ~20 years in the same flat as a professional translator and I know pretty well what these people expect. Their requirements are way higher than those of students wanting to put a few latin quotes in their work assignments. And they're not the same people that do professional formatting. Asking them to use the same controls is a big mistake. The whole point of styles is to separate presentation from content and here you put content elements in the presentation layer (actually there should also be a document structure layer, but that's another problem) Regards, -- Nicolas Mailhot
Re: [discuss] Re: re: Massachussetts registered voters
Le jeudi 27 octobre 2005 à 20:35 +0100, Daniel Carrera a écrit : Nicolas Mailhot wrote: Well, date formats are not going to severely hinder interoperability. You're being as naïve as Chad there. Business processes depend on exchanging documents containing dates in a standard format. No need to be offensive :) If I'm wrong just show me where I'm wrong and I'll learn. Notice that I included the word *severely*. I haven't yet seen dates become a severe problem, though I can certainly see how they are a _problem_. And for that reason, I use a format that I know will be inmediately understandable by my audience. Since my audience usually comprises a mix of English speakers who can't agree whether to use MM-DD-YY or DD-MM-YY, I usually pick DD-MMM- which they all get. Actually because of daylight saving times and all the timezones that exist you need something more complete nowadays. For example -MM-DDTZD as the W3C ISO propose (http://www.w3.org/TR/NOTE-datetime) Adding timezone means people in another country will be able to convert if needed. Adding explicit timezone (time differential with UTC) means if you're in a country that does DST the day it happens you know if you're before of after the switching point. In my country for example railroad control systems were developed using local date/time reference. As a result they have to stop every single train in the country one hour every year, because this hour does not exist for the control systems and it would be dangerous to let trains move. Simple dates are ok when you don't care about precision. In a global economy where you work with people all around the world and systems are supposed to be up 24h a day every single day of the year, this simplicity is a luxury less and less people will be able to afford. (I've given one well-publicised example - I've seen others in my day job but I'm not supposed to leak them) Regards, -- Nicolas Mailhot
Re: [discuss] Re: re: Massachussetts registered voters
Le jeudi 27 octobre 2005 à 22:12 +0100, Daniel Carrera a écrit : When I post a time that is relevant for an international audience (e.g. the time of an IRC meeting) I post it in UTC. Well you might be happy to learn the W3C/ISO convention in this case is to just append Z to the date/time ( which earned UTC time the nickname of Zulu time) Regards, -- Nicolas Mailhot
Re: [discuss] Mixed language text spellchecking question
Le mardi 25 octobre 2005 à 23:23 +0200, cono a écrit : Your explanation doesn't make clear to me, why it is wrong. Aplying a character-style to a word, changes the language of that word, so that spell-checking can do its work. All other properties of the words (font etc.) can be the same. What do you suggest? Language should really be pushed to a space orthogonal to styling, with a separate UI to set it. Right now mixing language with styling : - confuses users - makes them more work (a language does not exist before a style is defined) - and I may be wrong there, but can you apply multiple character styles to the same word ? If not as soon as you need it for language you've lost it for its usual styling purpose (sure you can do fixed text with russian fixed text with french but this example shows clearly 1. you're trying to shove two different things in the same slot 2. you've multiplied the styling work required of the user) Separating language from styles would permit : - syncing the language with input method (what this user asked) - displaying the current language so users can actually know what happens in the status bar (ie this § is spellchecked against american english, not british english) - and a lot of other cool language-management enhancements (language-specific word count, highlighting of a specific language when you want a native speaker to check these parts, etc), which are not possible right now when language is hidden in styles -- Nicolas Mailhot
Re: [discuss] Mixed language text spellchecking question
Le mercredi 26 octobre 2005 à 18:43 +0200, Mathias Bauer a écrit : I'm not sure wether language being content or style is the only way to solve the problem of Anton. Shouldn't it be sufficient if the applied style went with the used input locale? But how do you choose which style to apply ? If you don't create a very simple style that only specifies language, there is bound to be bad juju interaction with formatting. Also if you go through styles that means users will have to set up what style to apply with what input every time they change documents (unless of course they use the same set of style for every single document they modify) Now, if you use simple styles with only language attribute (to avoid interactions with presentation) and fixed names (to avoid reconfiguring OO.o every time you load a new document) wouldn't it have been so much easier to access language directly in the first place ? -- Nicolas Mailhot
Re: [discuss] Mixed language text spellchecking question
Le mercredi 26 octobre 2005 à 22:32 +0200, cono a écrit : Nicolas Mailhot wrote: Le mercredi 26 octobre 2005 à 18:43 +0200, Mathias Bauer a écrit : [...] Now, if you use simple styles with only language attribute (to avoid interactions with presentation) and fixed names (to avoid reconfiguring OO.o every time you load a new document) wouldn't it have been so much easier to access language directly in the first place ? Something as - adding a character-style for every language you use to the standard template; - assigning the styles to a key-combination ? That's pretty much the only kind of workaround you can do if you work at at a department-level. It won't solve the problem of SOHO and single users, and it won't solve the problems of multinationals with branches in many countries, but that's the only thing doable with the current OO.o version. And all it does is extract the info you need to set from the style structure that has been forced around it, and the style indirection means you'll have problems every time you need to work with someone who used slightly different conventions. From a pure UI POW what most users expect is a dropdown control with a language list in the toolbar (like for styles, but strictly limited to language), and a key accel to quickly switch between the languages which have already been used in the doco. Even users that want to sync presentation changes with language changes would probably be better served by some sort of conditional styling than by what we have today (ie allow to define variants on a single style based on the encoding of the text styled. And then only offer the root style in the style dropdown) But then good internationalisation is something very new and foreign to traditional closed software houses, unicode is not the natural way of working yet and OO.o shows its SO roots. When encoding restrictions made documents with a high language mix a technical impossibility, the pressure to handle languages well was not so big. I just hope someone gets thing into shape soon. That's the kind of misdesign MS would love to point out to journalists and politicians. -- Nicolas Mailhot
Re: [discuss] Mixed language text spellchecking question
Le mardi 25 octobre 2005 à 19:18 +0200, cono a écrit : Hi Anton, Anton I. Danilov wrote: [...] As for the single language text is concerned, spellchecking goes ok. If text's language is Russian, you can select Format - Character - Language (Russian) and spellchecker will do its job for Russian language. The same situation for a plain English text. But when the text is mixed, with parts in English and parts in any other language, OpenOffice does not switch the charater language properties according to the switching input locale. [...] Have you tried defining different styles for the various languesges? Thus you assign a Russian or an X-language style to the words/paragraphs. That's what OO.o wants you to do and it's WRONG. You can take a sentence in any language and make it red bold big small, promote it to title status etc. That what's styling is about. Style is something you can apply regardless of what the content actually is. OTOH you'll never make a french sentence correct russian just by changing its style. Language is an intrinsic quality of what has been typed, it can not be styled. The awful kludge OO.o uses (making language a style attribute) only works with documents that have light language mixes and high structural requests. It's totally unadapted to the vast majority of multilingual documents, where language can change in the middle of sentences and you want presentation to be the same regardless of what language is used (that's why professional multilingual documents do not look like collages of different presentation styles). -- Nicolas Mailhot
Re: [discuss] Mixed language text spellchecking question
Le lundi 24 octobre 2005 à 14:52 +0400, Anton I. Danilov a écrit : It's not quite clear, is there such a function in OO, that switches the character properties according to the current input locale, as MS Office does, or not? It's actually worse than that since some languages can be entered using the same method (language groups like west and east european languages), and there's absolutely no easy way to tell manually OO.o you just switched languages. OO.o authors consider language part of the styling, when in fact language is part of the content, and as a result you get the current mess (for people who have to work with multiple languages, which is not the majority, but not a small minority either). I'm afraid language=style is deeply embedded in OO.o and there's no way to fix this easily. -- Nicolas Mailhot
