Re: [tdf-discuss] test mail
On 2011-07-10, Steve Edmonds wrote: > On 9/07/11 6:35 AM, Christophe Strobbe wrote: > >> Some of my mails never reach the list... > > For some reason (some setting I have) on one PC I do not see my emails > received from the list when I send them to the list. I am using Google > hosted domain and the mail shows up in sent but not in the list when I > view it. Replies to my emaisl do show up though. I don't know how google hosted domains work, but maybe it's like Gmail. Gmail won't let you have two copies of the same message, so if you send the message through google's mail system, the list *will* send you your own message, but gmail discards it, because it's a duplicate (same Message-Id). -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] New "LibreOffice Reader" Eliminates Need for "PDF Reader"
On 2011-06-25, Ian Lynch wrote: > On 25 June 2011 10:02, timofonic timofonic wrote: > >> On Fri, Jun 24, 2011 at 3:42 AM, Nuno J. Silva >> wrote: >> > On 2011-06-24, Andrea Pescetti wrote: >> > >> >> This, however, won't work. Document fidelity is not the aim of ODT >> >> files, while it is the aim of PDF files (example: font embedding, but >> >> one could find many more). Replacing PDF by ODT is just not feasible due >> >> to the formats themselves, not to the lack of an "ODF Reader". >> > >> > Font embedding is an issue, it could render the viewer useless. >> > >> > It's possible, at least, to make some room for "compatible documents", >> > by shipping a set of fonts with the viewer and announcing that as the >> > "standard fonts" for ODF viewer. >> > >> > Unless there's some required feature of ODT that's not possible to >> > reproduce in PDF, I suggest keeping with PDF for now: it is designed for >> > portability and it's vectorial, so there's no loss. [...] > What is the purpose of pdf? It's for putting documents on paper. If you > simply want to read a document on screen use a browser. There was a project > to develop a Firefox plugin through the OpenDocument Fellowship but I think > it has stalled. I would rather encourage people to read screen based stuff > with a browser instead of having to download pdfs when the information is > rarely ever printed. If it needs to be LibO will produce a pdf to do it. > Seems to me that a browser plugin is a lot simpler task and a lot more > useful. Get Google to sponsor it for Chrome. You're right, if the idea is an onscreen reader, something that just renders the content on-screen using available fonts and some user-defined settings (color scheme, monospace, text width, ...) would be way more useful than something that's concerned with freezing the look'n'feel of the document. Just like html is supposed to work. -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Re: Font Embedding in ODF
On 2011-06-25, Andrew Douglas Pitonyak wrote: > On 06/25/2011 02:09 PM, Nuno J. Silva wrote: > >> I see font embedding as a way to make interoperation easier, and not to >> achieve faithful representation. I think a major goal is to have ODF >> being used on several platforms, and available fonts differ from >> platform to platform. OTOH I guess LibO can (and probably already does?) >> bundle some fonts with it, so that the default fonts are available on >> every install of LibO (but this still excludes other ODF-compatible >> applications). > > I always wondered how embedding fonts worked from a copyright > perspective. I use my favorite special font that I purchased for my > own use, then I create a document that uses (and embeds) that font in > the document. At least the TrueType format has an "embeddable flag", which should say whether the font can be shared, embed in a document, etc.: ,[http://enwp.org/TrueType#Embedding_protection] | Embedding protection | | The TrueType format allows for the most basic type of digital rights | management – an embeddable flag that specifies if author allows | embedding of the font file into things like PDF files and | websites.[...] ` An ideal approach would be raising a warning when embedding a "protected" font in a forbidden way. But of course this wouldn't suit the hungry US legislation -- there LibO would probably need to completely forbid embedding "protected" fonts (even if there is no way to know if the document with embed fonts is going to be shared). See http://www.planetpdf.com/mainpage.asp?webpageid=2402 for an example of DMCA in action. I think that, in case LibO embeds fonts, this _just_ means LibO must respect that bit. But I might be wrong. -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Re: Font Embedding in ODF
On 2011-06-25, Dennis E. Hamilton wrote: >> Dennis E. Hamilton wrote: >> >>> Le 2011-06-24 13:13, Charles-H. Schulz a écrit : >>> >>>> So, let me state and restate this : ODF will not embed fonts in the >>>> 1.2, 1.3, nor in the future, because the format is not meant to focus on >>>> faithful layout rendering. Instead, PDF is meant that. ODF focuses on >>>> office document exchanges. >>>> >>> >>> 4. It is incorrect to presume that Font Embedding will not be in ODF 1.3 >>> or any other. While font embedding did not make the feature cut in the >>> prioritization for ODF 1.2, that does not mean it can't be resurrected. >>> It is early days for ODF 1.3, which is scheduled to take a two-year >>> development process. >>> What is *missing* is a serious proposal that deals with the >>> complexities, borrows from some already-worked-out approach in other >>> software, and is brought forth at the ODF TC in an unencumbered form. >>> Someone has to do the heavy lifting. [...] > I think this conversation needs to be made more concrete. > > The inclusion of font embedding into the ODF 1.x specification is not > the issue. > > The issue is, who has it be such an imperative that they are willing > to have and document an implementation-specific solution well enough > that others can interoperate with it. Then, or concurrently, it can > be rolled into the ODF specification work as the basis for an > independently-implementable, interoperable feature of ODF. The problem is that the research I've been doing about this subject has been leading me to the position that LibO/OOo is not going to implement it because it must be implemented in ODF, and because ODF won't support that. So, after reading your messages, there are two issues: 1. There's a misunderstanding of the position held by the ODF TC (or maybe it was some decision taken long ago of which you don't know?), and 2. this sounds like a chicken and egg problem, LibO/OOo will only implement embedding if it gets in ODF, and it will only get in ODF if there's a working implementation. I've always held the opinion the chicken must have come first, because "egg" is shorthand for "[chicken] egg". But I doubt this helps here. > The ODF TC does not implement anything. And it is a waste of the > volunteer efforts of the ODF TC participants to specify features that > no one implements or that are not practically implementable or for > which there are already good-enough solutions that can be adapted. > There's a hand-and-glove partnership required for a feature as > substantial as font embedding. Makes sense. [...] > It is definitely the case that the ODF specification does > not specify the rendering and presentation of documents. But that > doesn't exclude font embedding. After all, there are already > significant provisions for fonts in ODF, they just don't encompass > embedding font files. I see font embedding as a way to make interoperation easier, and not to achieve faithful representation. I think a major goal is to have ODF being used on several platforms, and available fonts differ from platform to platform. OTOH I guess LibO can (and probably already does?) bundle some fonts with it, so that the default fonts are available on every install of LibO (but this still excludes other ODF-compatible applications). -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] New "LibreOffice Reader" Eliminates Need for "PDF Reader"
On 2011-06-24, Robert Derman wrote:
> Varun Mittal wrote:
>> I personally feel we have more important set of priorities than diversifying
>> right now into PDF reader. Also no point inventing the wheel again when
>> there are several open source pdf readers available which we can integrate
>> instead of developing one of our own.
>
> I am wondering do any of the open source pdf readers mentioned above
> work with Windows or are they all Linux, I mostly use Windows. What I
> meant by HUGE when I referred to Adobe Reader was the more than 6 Gigs
> of hard drive space it takes up! By contrast all of the LibreOffice
> suite of programs takes up 475 Megs of space. That means that a mere
> reader takes up more than a dozen times the space of an entire office
> suite. If that isn't mega-bloat I don't know what is. It has been a
> long time, but I seem to remember Adobe Reader only taking 12 Megs of
> space at one time. It used to come included on almost all driver
> disks, now it is just too big for that.
Adobe Reader is the only bloated PDF reader I've seen so far, when it
comes to runtime. Heavy, slow to launch.
I know Evince runs in Windows, just see its download page
http://live.gnome.org/Evince/Downloads
Or a direct link to the current version:
http://ftp.gnome.org/pub/GNOME/binaries/win32/evince/2.32/evince-2.32.0-144.1.msi
Evince 2.30.3 in a Windows VM I have around takes 70.3 MiB of disk
space. Now I guess part of that are the dependencies, libraries that are
frequently around in GNU/Linux but must be supplied in windows.
OTOH it's way lighter than Adobe Reader, and it supports more than just
PDF (it also supports PostScript, DeJaVU and LaTeX DeVice Independent;
it's able to handle comics packed in some compression formats ("cbr",
"cbz" and others)).
Coming back on-topic, there was once some talk about adding [to Evince]
support for viewing editable documents. The following reply by a member
of the Evince team, who says why he thinks it shouldn't be done, sounds
interesting in the context of this thread (the one I'm replying to):
http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00159.html
There are also some comments on their wiki webpage (see the last
section, /Possible or Planned to Support/):
http://live.gnome.org/Evince/SupportedDocumentFormats
>> My 2 cents !
My 2 cents, too. So total = 4 ;-)
--
Nuno J. Silva (aka njsg)
gopher://sdf-eu.org/1/users/njsg
--
Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.documentfoundation.org/www/discuss/
All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Re: ANN: ODF 1.2 Candidate OASIS Standard Enters 60-Day Public Review, prerequisite for balloting as OASIS Standard
On 2011-06-24, Marc Paré wrote: > Le 2011-06-24 13:13, Charles-H. Schulz a écrit : >> Hello, >> >> Le Fri, 24 Jun 2011 07:48:54 -0700 (PDT), >> plino a écrit : >> >>> I really hope that revision 1.2 allows for font embedding in ODF >>> documents. >>> >>> IMO that is a (the?) major obstacle for sharing documents with other >>> users. >> >> So, let me state and restate this : ODF will not embed fonts in the >> 1.2, 1.3, nor in the future, because the format is not meant to focus on >> faithful layout rendering. Instead, PDF is meant that. ODF focuses on >> office document exchanges. >> > I wonder about this last statement, does this mean that if I download > a copy of our documentation in .odt format, that if my font is missing > from my machine that I will not be able to print a high quality > version of that documentation. You will be able to print an high-quality version. It will just use another font. I mean, you lose quality in the meaning the font used is not the intended, but you don't lose quality as in definition or content. > And worse, if I download a copy of a > writer, impress file or draw and wish to print it off in its native > file, that I would then have to hunt around and make sure that all of > the necessary fonts used in a particular document would have to be > installed on my machine so that I could get a high quality print from > it? To be sure documents print the same way in different computers, you should use Adobe PostScript or Adobe Portable Document Format. I don't mean font embedding is not needed, but just that you're looking into a part of the problem that already has a solution, as far as you don't need the document to be editable. -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] New "LibreOffice Reader" Eliminates Need for "PDF Reader"
On 2011-06-24, Andrea Pescetti wrote: > Marc Paré wrote: >> if we were to promote a "quick and dirty" >> "LibreOffice Reader", very much like the "Adobe Acrobat Reader", whose >> sole purpose is to provide the ability to "read" ".odt" files, there >> would be no need to carry .pdf formatted files. Heh. :-) Don't use Adobe Reader as an example of a "reader", use instead some other PDF reader with a reasonable memory and disk space footprint. (Unless that's what you meant by "quick and dirty".) > This, however, won't work. Document fidelity is not the aim of ODT > files, while it is the aim of PDF files (example: font embedding, but > one could find many more). Replacing PDF by ODT is just not feasible due > to the formats themselves, not to the lack of an "ODF Reader". Font embedding is an issue, it could render the viewer useless. It's possible, at least, to make some room for "compatible documents", by shipping a set of fonts with the viewer and announcing that as the "standard fonts" for ODF viewer. Unless there's some required feature of ODT that's not possible to reproduce in PDF, I suggest keeping with PDF for now: it is designed for portability and it's vectorial, so there's no loss. Someone suggested djvu (DeJaVU). I like djvu, I use it and I and spread the word about it, but IMHO it's main use is for scanned documents (making it so entire books can fit in a floppy!). Even if a pdf is larger than a djvu for the same document, if it was directly exported to pdf, it's vectorial. Converting to djvu makes it raster. IMHO that's a bad idea. YMMV. -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [tdf-discuss] Re: EasyHack on EasyHacks
Michael Meeks writes: > On Tue, 2011-03-29 at 22:51 +0200, Bjoern Michaelsen wrote: >> Hi Nuno, > > First - great work :-) and good to have you helping out here Nuno. Thanks :-) > Second - this is a page of incredible importance to developers, and as > such - any changes to it need to be discussed and decided on the > developer list. > > Thirdly - I'd like to see it changed only after more thought, and I am > out tomorrow so can't be involved in that. I'll try to keep the split draft up-to-date, while playing around with the structure. All in this "sandbox", of course. I agree this should only be changed if people agree, and after being sure it is actually better this way. > >> > I made an attempt to split it under my user pages, >> > http://wiki.documentfoundation.org/User:Njsg/EasyHacksIndex >> >> Looking great IMHO! > > Personally I dislike pages that fragment and hide the information I'm > looking for behind some high-latency switch-tab / middle-click / > re-load-page stuff. They also tend to make it much harder to search > within that category quickly (ctrl-F style), now I have to do > ctrl-F/alt-N/switch-tab/ctrl-F/alt-N/alt-N/switch-tab/ctrl-F etc. etc. It is harder. I dislike these too :-). > I agree the information is not as cleanly structured as it could be; > and that perhaps a separate index to the same data might be good (though > it might also have maintenance problems). Possibly just re-structuring > that page would help. This is split into several pages, but it is possible to join it again in a single list, after all the subpages are just parts of a big list. It is a restructuring that happened to involve splitting. Also, maybe it is possible to have /both/ split-lists and single-list versions. For a quick and rough attempt, see http://wiki.documentfoundation.org/User:Njsg/EasyHacksFullList, which just includes the content of the split lists. (But the headings from the split lists are messing the full list page, hence "rough".) The list is big, thus the idea of splitting. But, as you say, re-structuring will probably help too. Either I misclassified many hacks as "cleanup", or there are many of them, making the cleanup hacks list harder to read in the same way the original list is: http://wiki.documentfoundation.org/User:Njsg/EasyHacks/cleanup -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentfoundation.org/www/discuss/ *All messages sent to this list will be publicly archived and cannot be deleted*
[tdf-discuss] Re: EasyHack on EasyHacks
Bjoern Michaelsen writes: > Our "EasyHacks" page here: > > http://wiki.documentfoundation.org/Development/Easy_Hacks > > is quite a mess by now as we have so many of them. Also I dont think it > is very inviting to newcomers. An really important "EasyHack" -- that > does not even require elite programming skills would be to split that > page into multiple topics, so that contributors can find something for > their skillset. A possible splitup would be: > > - Infrastructure (skills: bug trackers, mailinglists, web stuff) > - build system (skills: perl, scripting, building) > - testing (skill: build, tools like valgrind) > - code cleanup (skills: beginners C++) > - UI improvements (skills: C++) > > Any volunteers? I made an attempt to split it under my user pages, http://wiki.documentfoundation.org/User:Njsg/EasyHacksIndex It is based on the Easy Hacks page as of 2011-03-29T13:52:51 (http://wiki.documentfoundation.org/index.php?title=Development/Easy_Hacks&oldid=18812). It needs some cleanup (empty lines and empty sections), which I'll now do. I should also change heading levels so that the root ones are the top level, but for now I didn't change that, to keep the text blocks unchanged. Although it lists these skill sets you pointed out, some tasks (maybe most of them?) require other skills -- I tried to group tasks based on what each list is about, but there's probably some room for improvement. I hope this is helpful. -- Nuno J. Silva (aka njsg) gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://listarchives.documentfoundation.org/www/discuss/ *** All posts to this list are publicly archived for eternity ***
[tdf-discuss] Re: Bug or new feature
Steve Edmonds writes: > Thanks, I get by with PS2PDF but don't get the table of contents > working. Yes, AFAIK postscript doesn't support that. If there's some tool that is able to extract and add bookmark information to a PDF, you can try generating the PDF directly from LibO and injecting its bookmarks into the one generated by ps2pdf. > With SVG support, may be a conversion of my EPS's to SVG will solve the > problem. > Cheers, steve > > On 15/03/11 21:04, Fernand Vanrie wrote: >> Steve, >> >> I filed 2 years ago a issue on OO for that. >> Indeed it blocks a lot of efforts made to make PDF happen, and the >> tool is still useless for many (professional) users. EPSvector is >> still the standard for all graphic applications. >> Like Micheal says, the code needs a bit more love :-) Some warm, loving love :-) There are at least two issues in OOo bugzilla involving encapsulated postscript - If there is no preview bitmap in the EPS, OOo will generate one. That takes some time, and the preview gets cached, and therefore it can be uncached. I personally saw the worst possible effects of this: a document with several big EPS images would take long scrolling up and down. http://openoffice.org/bugzilla/show_bug.cgi?id=77068 - The one this thread is about: http://openoffice.org/bugzilla/show_bug.cgi?id=14163 But, in a nutshell, it is not easy: embedding postscript in PDF needs some kind of conversion. It's not only LibO and OOo, pdflatex also needs vectorial pictures to be in PDF. Rendering eps in OOo/LibO is quite harder than rendering other vectorial formats, because postscript is a programming language, so LibO would need to understand postscript, and would still have to re-interpret it each time the image is displayed. But I'm glad it supports EPS the way it does, it is already helpful. Even if I have to print to postscript, at least I can use eps images directly. >> >> Greetz >> >> Fernand >>> LO, also OO do not create pdf's correctly from documents containing >>> EPS's. >>> This occurs on 3.3.1 on Suse and OSX. >>> The PDF is not created with the vector data of the EPS but the low >>> resolution bitmap (if there is one) used for positioning. >>> To create a correct PDF I must print to file (PS) and use PS2PDF. >>> >>> Is this a bug? >>> >>> steve >>> >> >> -- Nuno J. Silva gopher://sdf-eu.org/1/users/njsg -- Unsubscribe instructions: E-mail to discuss+h...@documentfoundation.org Archive: http://listarchives.documentfoundation.org/www/discuss/ *** All posts to this list are publicly archived for eternity ***
