Aw: Re: Forced Updates? WTF?

[Christoph Schäfer]

> Gesendet: Dienstag, 09. Juni 2020 um 09:36 Uhr
> Von: "Mike Kaganski" 
> An: "Christoph Schäfer" , 
> LibreOffice@lists.freedesktop.org
> Betreff: Re: Forced Updates? WTF?
>
> On 09.06.2020 3:22, Christoph Schäfer wrote:
> > I never thought this was possible with LO, but it looks like the developers 
> > have chosen to override my default settings (notification, but no automatic 
> > updates). Yet, an update from 6.3 to 6.4 (Windows 10) has been enforced on 
> > me, which also led to data loss, as well as losing the "Recently Used" 
> > entries in the File dialogue.
> > 
> > 
> > If this wasn't an attempt by Microsoft to damage LO (I'm on Windows 10), I 
> > have to ask: What the hell were you thinking?
> > 
> > 
> > This is unacceptable.
> 
> ... so re-wording all that, "I don't know what had happened; and I don't
> tell you all the details (like how had I installed LO in the first place
> - e.g. from MSI taken from TDF site, or from Windows Store); and which
> "helpful software" might be installed on my system helping to keep
> software "up-to-date"; and I even don't know if that was some deliberate
> decision, or a bug, - but I choose to be rude from start."
> 
> I doubt it being acceptable.
> 
> -- 

Hi,

It's true, I don't know what happened. I originally installed LO via the MSI 
installers from the TDF site, and I have no other "helpful software" regarding 
updates on my computers. Oh, wait, on my laptop I have installed a Windows 
update blocker, and yet the LO update happened in the background. At least on 
the laptop the "Recently Used" list wasn't lost, but the icon set reverted to 
the default setting. On my PC even the list was lost, the icon set was also 
changed, and the document restauration didn't work after the PC was forced to 
reboot, so I lost some work.

If TDF is responsible for this (and I added a qualifier to my original post), I 
actually consider this to be rude behaviour.

Christoph


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Forced Updates? WTF?

[Christoph Schäfer]

Hi,


I never thought this was possible with LO, but it looks like the developers 
have chosen to override my default settings (notification, but no automatic 
updates). Yet, an update from 6.3 to 6.4 (Windows 10) has been enforced on me, 
which also led to data loss, as well as losing the "Recently Used" entries in 
the File dialogue.


If this wasn't an attempt by Microsoft to damage LO (I'm on Windows 10), I have 
to ask: What the hell were you thinking?


This is unacceptable.


Christoph
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

PDF/A support in LibreOffice

[Christoph Schäfer]

Hi,



I have three questions regarding LibreOffice's implementation of the PDF/A 
standard. First, how did you manage to do this? Did you have access to the ISO 
spec? And if so, would you be prepared to share the spec (or the required 
information) with other open source projects?


The third question is related to the different PDF/A versions. As far as I can 
see, LO currently only supports the original PDF/A spec. Are there any plans to 
support versions 2 and 3?



Kind regards,
Christoph Schäfer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Scribus 1.5.4 Released

[Christoph Schäfer]

The Scribus Team is pleased to announce the release of the stable development 
version 1.5.4, which is in many ways a new milestone on our way to the next 
officially stable release 1.6.0.


Most important changes

- Color precision for fill colors has been expanded to 64 bit floating point.

- Scribus can now handle color palettes in the new ISO standard CxF3 (See: 
https://www.xrite.com/de/page/cxf-color-exchange-format). CxF3 files cannot 
only store palettes in different color models (e.g., RGB, CMYK, LAB) and output 
intents, but also allow for storing spectral colors, which enables even greater 
colour precision. Scribus is the first DTP software that supports this 
demanding standard.

- Existing import filters have been upgraded to support the LAB color model 
(where applicable).

- The Barcode plug-in has been updated and offers new features.

- Many bugs regarding fringe uses have been fixed in the PDF library, both for 
print PDFs and PDF forms.

- Several new commands have been added to the scripting engine, so as to make 
the document creation via scripts easier and more versatile.

- Thanks to the work of the Document Liberation Project and particularly David 
Tardon, experimental import filters for ZonerDraw vector drawings (versions 4 
and 5) and QuarkXPress documents (versions 3 and 4) have been added.

- Many potential stability and security issues revealed by Coverity scans have 
been fixed.


The complete changelog is available here: 
https://bugs.scribus.net/changelog_page.php?version_id=99



Primary Download Locations

- Installation packages for Windows, Mac OS X and the source code are available 
here: https://sourceforge.net/projects/scribus/files/scribus-devel/1.5.4/

- OpenSUSE, SLED, and SLES RPMs: 
http://download.opensuse.org/repositories/home:/mrdocs

-Packaging for other Linux distributions, *BSD, Solaris and OpenIndiana is 
beyond our influence. We recommend updating the respective repository data on a 
regular basis.

- Windows Portable App: 
http://portableapps.com/apps/office/scribus_portable#test

Download Verification

Description File Name   Sha256sum   Sha1sum

Source  scribus-1.5.4.tar.xz
6480925250b2bb07028e2f378c02b67fe3e33206743671e03c07c701cd05da03
40a8819df4572a3fb752ecda38520a792f69c54f

Source  scribus-1.5.4.7z
c756037464cfc1f760ddad0cce5cc323d4091e65cd119dd1d69ad16be32b7d6 
414ee31a57c9789d890384f71f28f5641c2c1f79

OS X 10.10 or higher, Intel x64 scribus-1.5.4.dmg   
6f31b0b9bf27c952d820188343e2be73ab990be772e34551b030d9c04fa4f5b8
2c9d71dc7b2e589ad27b7817c755d64f441a72e4

Windows 32/64 Bit   scribus-1.5.4-windows.exe   
c8710ee2591f0e00b9c6506671c401ce2c54541ded55c043f74b2e622c07f2dd
80dc3701b35ae8ec99a1870c7d4228a72cb02755

Windows 64 Bit  scribus-1.5.4-windows-x64.exe   
2d11a7c04f2b58436541269e21227ce8676b62e908cc2b14987a865ca6d65170
64fd2cd02e0f6b99e208252cddd21d228bc479fb

Linux 64 bit AppImage   scribus-1.5.4-linux-x86_64.AppImage 
9c8bb1c491b5219093d98663e4810df1e8b317e23f349eebb5c1c2213a210f79
2bfd9a9486f0a8a8ec2c88bcc91029c6c1a265a5



The Scribus Team would like to thank Anduin.net and Modirum for their continued 
hosting of all of the Scribus websites.

We are grateful to the Organisation Internationale de la Francophonie for 
sponsoring.

The Scribus Team is also honored to have Resene Colours (New Zealand), dtp 
studio Oldenburg (Germany), Scientific Illustration Services Corp. (USA), the 
Newspaper Association of America (USA), Software Consulting Services (USA), 
freieFarbe e.V. (Germany), bauwerk Kommunikationsdesign (Germany) as Special 
Supporters and donors of color palettes and other content since the 1.4.x 
release, just like we are grateful to the owner of Vector Portal for the 
permission to distribute some of his work as Scribus Templates.

Porting Scribus to OS/2 and eComStation is being supported by Serenity Systems 
(USA).

Finally, the Scribus Team would like to thank the many end users, translators, 
testers and contributors who helped us with this release.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

HLC Colour Atlas v. 1.0 released

[Christoph Schäfer]

Hi all,



After a year of hard work freieFarbe/freeColour is pleased to announce the 
completion of its first major project, the "HLC Colour Atlas", which is a truly 
open colour system based on mathematics and unrestricted by copyrights or 
trademarks. It has been created by colour professionals from Germany and 
Switzerland.



The atlas comprises the following elements:


- a printed reference (A4, ring binder) of 2040 colours, based on the intuitive 
HLC colour model (Hue, Lightness, Chroma), with increments of 10 between each 
hue. It also includes colours that can't be reproduced in regular CMYK 
workflows (spot colours). Unlike commercial products, its colour precision is 
extremely high, with a DeltaE00 of 0.5, i.e. colour differences between two 
copies of the atlas can only be measured but not perceived, even by a trained 
eye. Each atlas is being produced with a Fogra-certified high-end proof printer 
on Fogra-certified paper by a Fogra-certified company. Each copy is also being 
shipped with a production record (ISO 12647-7:2016);


- a printed introduction and usage instructions in German and English;


- colour palettes with LAB values for Adobe software (ASE format) and in 
Swatchbooker's SBZ format, as well as sRGB versions for LibreOffice (SOC), GIMP 
(GPL) and Scribus 1.4.x (XML). Please note that Scribus 1.5.x already includes 
the SBZ file, and an sRGB version is being shipped with LibreOffice since 
version 5.4.x, as well as the current officially stable Scribus 1.4.6.


- A PDF master file of the atlas with layers for different output targets (e.g. 
sRGB, ISOCoatedV2);


- XSLX files with colour conversion tables and QC report;


- a CxF v.3 file which includes the colour data in spectral values.


All files are available for download here: 
https://www.freiefarbe.de/thema-farbe/software/


The latter is important, because we want to enable others to create their own 
reliable references without having to ask for permission or paying licence 
fees. Thus, an ink manufacturer can simply load the CxF file into its 
formulation software and create the correct mix for his particular inks. 
Manufacturers of other colourants (e.g. paint, textile colours or plastics) can 
do the same, provided their software is supporting CxF, which is an open 
standard. This is also the reason for us not to publish any mixing recipes, 
because all necessary data to reliably recreate a colour are in the CxF file, 
so the recipes can be created and customised by software.


Whilst the digital files are available for free download under a CC licence, 
the printed reference needs to be paid for, because production and 
certification are quite labour-intensive (introductory offer: EUR 99.-- until 
31 March 2018, later: EUR 149.-- plus VAT and shipment costs; see: 
https://shop.proof.de/index.php?language=en).


freieFarbe/freeColour are convinced that the "HLC Colour Atlas" is not only a 
true and open alternative to Pantone, HKS etc., but we also think that the very 
high quality standard of our printed reference will be hard to match. 


Our next step is to fill in the necessary paperwork to make this open colour 
system a DIN SPEC with the German industrial standards organisation DIN 
(April/May 2018). From there it will hopefully be moved on to ISO to make it an 
international standard (time frame unknown).


Special credits go to Matthias Betz, Holger Everding, Jan-Peter Homann and Eric 
A. Soder, who did all the heavy lifting, as well as Gregory Pittman, who wrote 
a Scribus script that reduced the creation of the print PDF for the Atlas to a 
matter of seconds. freieFarbe/freeColour is also grateful to ColorLogic GmbH, 
Epson Deutschland GmbH and GMG GmbH & Co KG for generous technical support. The 
high quality of the atlas is owed to the producer, Proof GmbH.



Christoph
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Aw: Re: freieFarbe/freeColour HLC colour system to be accepted as a national standard for "Open Colour Communication" in Germany

[Christoph Schäfer]

Hi Stuart,



Please forget the dtp studio PDF file. It's outdated and was never meant to be 
a digital colour reference, only a preview of the physical product.


The new PDF will be a multi-layer file, with colour values for several output 
targets (spectral colours, L*a*b*, sRGB, at least one CMYK target, probably ISO 
Coated v.2).


There will also be a new SOC file available (unless you plan to implement an 
import filter for CxF files), which will be called "DIN-CIEHLC" or something 
like that. Since CxF allows multiple versions of the "same" colours in one 
file, we'll probably release one single CxF palette with at least spectral 
colours, L*a*b* colours and sRGB colours.


Christoph


> Gesendet: Sonntag, 03. Dezember 2017 um 20:51 Uhr
> Von: "V Stuart Foote" <vstuart.fo...@utsa.edu>
> An: libreoffice@lists.freedesktop.org
> Betreff: Re: freieFarbe/freeColour HLC colour system to be accepted as a 
> national standard for "Open Colour Communication" in Germany
>
> "Christoph Schäfer" wrote
> > ...
> > 
> > Currently, an older version of the HLC palette is already included in
> > Scribus 1.5.3+ (L*a*b*) and the latest LibreOffice (sRGB). And speaking of
> > Scribus, the juicy bit is that the colour reference will most likely be
> > produced with Scribus 1.5.4svn, because it offers the highest colour
> > precision for fill colours (64 bit). No other DTP software comes close in
> > this regard.
> 
> Christoph, *
> 
> This is a logical progression and well received, congratulations!  
> 
> So LibreOffice now needs to verify our sRGB .soc palette to matches the sRGB
> values for the HLC/CIE Lab colors submitted to DIN.
> 
> As noted in our BZ tdf#104052 when we implemented an HLC color palette, the
> dtpStudio prepared PDF color fan had listed sRGB values for each HLC color
> could differ considerably from the sRGB color values of   freecolour-hlc.soc
> <https://opengrok.libreoffice.org/xref/core/extras/source/palettes/freecolour-hlc.soc>
>   
> we distribute.
> 
> Not wrong (the CIELAB color conversion to sRGB depends on algorithm
> used--adobe CMS vs little-CMS2 and ICC profile) but we need to assure that
> our published .soc file matches what has been submitted to DIN.  
> 
> Would you please post the sRGB listing of the DIN submission to the TDF BZ
> issue [1]?
> 
> Thanks!
> 
> Stuart
> 
> =-ref-=
> [1] https://bugs.documentfoundation.org/show_bug.cgi?id=104052
> 
> 
> 
> --
> Sent from: http://nabble.documentfoundation.org/Dev-f1639786.html
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Aw: Re: [CREATE] freieFarbe/freeColour HLC colour system to be accepted as a national standard for "Open Colour Communication" in Germany

[Christoph Schäfer]

Hi Susan and the rest,

 

 

I'll reply to everyone in one mail, so the information doesn't get scattered all over the place.

 

 

> This is huge...
> This opens another area of proprietary design which affects the fashion industry.



Yes you are correct. This is huge and might affect the textile industry as well. DIN accepted our proposal because we argued as follows:


1) If a proprietary colour spec is being used in workflows, everyone needs a licence, so the choice of one person or group affects everyone else (vertical barrier).


2) It gets even worse across sectors. Imagine you just selected that nice Pantone spot colour for your company logo. Now you want to paint your company building in that colour and tell the painter/paint vendor "I want Pantone X-Y-Z". The likely answer ist "We don't do Pantone; we have our own colour system. Here's a reference, choose your colour." (horizontal barrier 1)


3) Today, many companies produce across countries, which only accelerates the problems. (horizontal barrier 2) This is the reason as to why DIN plans to take this colour standard to ISO later and make it an international standard.


The reason for starting with print was simply that all of the experts working on this are working in the printing industry. Plus, one of our partners is FOGRA (https://www.fogra.de/index.php?menuid=1=en), which is the leading organisation for printing standards in Europe and beyond.


Q:


"Since you already have a prototype, are you talking about metallic inks?"


No, metallic inks are off the table for now, as are neons. The prototypes have been created on VERY expensive inkjet printers with more than four inks. This is not feasible for regular print runs. The prototypes only served as a proof of concept for DIN.


"How do you define a real color system?"


As a system ;) In a system you can calculate e.g. complementary colours or colour harmonies. Pantone is just a collection of colours that was expanded and changed over the decades. There is no system behind it. NCS, on the other hand, is a real commercial colour system.


"Better in what way?"


It's open, free, and it uses LAB/HLC, so it covers the whole spectrum of colours visible to the human eye. Plus, unlike, e.g. Pantone, it's impossible to change the colour values or remove a colour from the system, because it's all based on physics and math.


"At what stage of work within DIN will ink formulas be published one way or another?"


At this stage (phase 5 of 9) it's not even sure that the ink formulas will be part of the DIN spec. Phase 5 means working with ink manufacturers to create the formulas. If they don't become part of the standard, they will become freely available from our website and/or become part of the printed reference.


"So my question is: from your LCH representation, can you ensure the creation of an ink so that 2 unrelated people could create the same color?"


Yes, once we have the ink formulas. That's what's currently being worked on.


"And from the printshop point of view, getting any spot color from the catalog is just about following a mixing recipe accurately, so it's easy and not too bothersome."


For the printshop maybe (not necessarily), but not for the ink manufacturers. These must pay licence fees to Pantone et al. for the use of the ink formulas. It's a bit like Monsanto, really. Plus, some Pantone inks are very hard to reproduce, because recipes are too fine-grained (e.g. one tenth of base colour x), and ink vendors have to juggle with 18 base colours for these recipes! This makes the production quite expensive. Add to that the experience of many in the printing industries that printed Pantone colour references are notoriously unreliable for various reasons. The HLC Colour Atlas, on the other hand, will be produced with strict quality controls in place.


As to the file format, the contract with DIN requires that we create two palettes in the CxF3 format (https://www.xrite.com/page/cxf-color-exchange-format), one with LAB values another one with spectral colours. The latter are even more precise than LAB, but I don't think any software supports it right now. We will make those available for download from our website and also add LAB-based versions as SBZ and ASE files, respectively. SBZ and ASE don't support spectral colours, so projects that want to use the latter need to write an import filter for CxF3 ;)


According to the current roadmap the final colour references and the digital palettes will be available in April 2018. The standard is supposed to be written by June 2018 and will then be published by DIN.


I hope I have answered all of your questions.

 

 

Christoph

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

freieFarbe/freeColour HLC colour system to be accepted as a national standard for "Open Colour Communication" in Germany

[Christoph Schäfer]

Hi all,



I have some incredible news for you.


Yesterday freieFarbe/freeColour received a message from the German industrial 
standards organisation (DIN) that our proposal for an open standard for "Open 
Colour Communication" based on the HLC colour model (aka as Lhc) has been 
accepted and will become a German national standard soon (because we have 
prepared this carefully during 2016 and 2017).


What does this mean? First, it will no longer be an initiative by a tiny 
non-profit organisation, but a national standard, and since DIN is very 
influential internationally, it will become a de-facto standard in other 
countries as well. Plus, it may be possible to make this an ISO standard via 
DIN.


In addition, DIN will support the formulation of the standard and our work with 
substantial sums, not the least because the creation of a standard and pushing 
its way through all the respective instances and expert checks is expensive 
(would've been 25,000 EUR in our case, which has been reduced to zero, because 
it's an open and non-commercial project). We will also receive some money for 
meetings, travel expenses etc. from DIN.


One of the reasons we got so far is support by parts of the printing industry 
in Germany and Switzerland. The prototype of the printed colour reference, 
which we presented to DIN, was only possible thanks to a donation of inks by an 
international manufacturer of digitial printing machines. We're currently 
cooperating with ink manufacturers in Germany and Switzerland to establish ink 
formulas for HLC colours that cannot be reproduced in CMYK, aka as spot 
colours, so printing companies can actually order spot colour inks by just 
inserting the HLC colour code in their order forms.


The printed colour reference has the form a ring binder. Colours are sorted by 
their H-values (H=Hue) in steps of ten. Luminacity (L) uses steps of five, and 
chroma (C) also steps of ten. We plan to refine this later to also present the 
H-values in steps of five.


This is a real colour system and not just a colour collection like Pantone or 
RAL. Most importantly, it is a free and open alternative to Pantone & co, which 
is not only better, but also supported by a national standards organisation and 
some major players in the industry. There are no licensing costs to pay for 
anyone who wants to use the colour system, not for software producers and 
neither for the ink mixing formulas. The latter is important, because vendors 
like Pantone ask for a lot of money from ink producers for the mixing formulas, 
whilst the open HLC system is gratis.


The PDF version of the colour reference and the digital colour palettes will be 
published under a CC licence (CC BY-ND 4.0). The printed colour reference will 
cost some money to cover the production costs, but it will be much cheaper than 
the ones from Pantone & co, because we only need to cover our expenses and do 
not intend/aren't allowed to as a non-profit organisation to commercialise it. 
Moreover, everyone else will be free to print their own references, and there 
are no trademarks involved.


Another important aspect is that the HLC colour system, being a national 
standard, will be very hard to attack legally by commercial vendors like 
Pantone or RAL, who are known to play hardball when it comes to competition. 
They would have to take on DIN, which I'm sure they'll think about twice.


We'll start with Germany and Switzerland, because that's where most of our 
members and supporters are from, but we plan to release an English version of 
the colour reference as soon as the colour system has been formally adapted as 
a standard.


Currently, an older version of the HLC palette is already included in Scribus 
1.5.3+ (L*a*b*) and the latest LibreOffice (sRGB). And speaking of Scribus, the 
juicy bit is that the colour reference will most likely be produced with 
Scribus 1.5.4svn, because it offers the highest colour precision for fill 
colours (64 bit). No other DTP software comes close in this regard.



Christoph
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Aw: Re: [libreoffice-design] Open Colour Systems Collection 2.0 released

[Christoph Schäfer]

Hi Heiko,

I'm not sure if I can handle this. It's probably easy to create an extension 
that just copies 376 colour palettes into a subdirectory, but IMNSHO it would 
make sense to create something more versatile, e.g., an OCSC palette manager 
that enables users to select the installation or de-installation of (in the 
alternative: activation or de-activation) of OCSC colour palettes.

Simply put, having additional 376 palettes available, most of which are special 
purpose ones, doesn't make much sense. Scribus uses a dedicated download 
service to let users choose what they need.

I certainly don't have the time to code this, but if anyone wants to get their 
hands dirty with trying, I'll be supportive.

Best,
Christoph



> Gesendet: Dienstag, 27. Dezember 2016 um 11:42 Uhr
> Von: "Heiko Tietze" <tietze.he...@googlemail.com>
> An: "Christoph Schäfer" <christoph-schae...@gmx.de>, 
> "designglobal.libreoffice.org" <des...@global.libreoffice.org>, libreoffice 
> <libreoffice@lists.freedesktop.org>
> Betreff: Re: [libreoffice-design] Open Colour Systems Collection 2.0 released
>
> Hi Christoph,
> 
> many thanks for sharing your work. In case of LibreOffice it would be great 
> to have these palettes as extensions. Just ask if you need help to pack the 
> soc files into oxt. But maintaining it on the extensions site is up to you 
> (or any other volunteer).
> 
> Cheers,
> Heiko
> 
> On 12/23/2016 08:01 AM, "Christoph Schäfer" wrote:
> > Open Colour Systems 2.0 Released
> > 
> > 
> > freieFarbe e.V. / freeColour is pleased to announce the release of Open 
> > Colour Systems Collection (OCSC) 2.0.
> > 
> > Following the release of OCSC 1.0, freieFarbe / freeColour has been been 
> > recognised by German authorities as a non-profit organisation. The release 
> > of OCSC is the first one after the official recognition.
> > 
> > OCSC 2.0 comprises ten additional colour palettes. More importantly, it is 
> > now also available in Adobe's Swatch Exchange Format (ASE), as well as a 
> > Plain Text Format version with the file extension CLF.
> > 
> > All colours have been measured from vendor-supplied colour references with 
> > a spectrophotometer.
> > 
> > Since freieFarbe e.V. / freeColour is an advocate of the use of the CIE 
> > LAB/HLC colour model as a free and reasonable alternative to proprietary 
> > colour collections, colour values in the palette files are in CIE LAB.
> > 
> > Download
> > 
> > 
> > SBZ: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_SBZ.zip
> > SHA1 checksum: 6b2bab7dde9e5fe9e8778ee9f79f31edcaa8cef8
> > 
> > ASE: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_ASE.zip
> > SHA1 checksum: fea350149e2b95af55f36e283fe597f279d3f79c
> > 
> > CLF: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_CLF.zip
> > SHA1 checksum: e65fd94db7f0d6484df9ce0cf0288ecd328ec655
> > 
> > 
> > In addition, OCSC 2.0 has been released in three RGB versions for use in 
> > LibreGraphics programmes that don't support the LAB colour model and/or one 
> > of the formats listed above (yet). The formats are: GPL (GIMP, Inkscape, 
> > Calligra Office, Krita, MyPaint), SOC (Apache OpenOffice, LibreOffice, 
> > OpenOffice.org), and XML (Scribus 1.4.x).
> > 
> > Download
> > 
> > 
> > GPL: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_GPL.zip
> > SHA1 checksum: c0eefb3a74f658c9c201d5671b4af6a085650cbb
> > 
> > SOC: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_SOC.zip
> > SHA1 checksum: 318d8fbaf391b0ec39fa433e807e3ec658381376
> > 
> > XML: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_ScrXML.zip
> > SHA1 checksum: da456792dc89445022ab4ae1af3f5ccedc722cd6
> > 
> > 
> > A complete package with all supported formats is available here: 
> > http://dtpstudio.de/downloads/freeware/OCSC_20.zip
> > SHA1 checksum: e65fd94db7f0d6484df9ce0cf0288ecd328ec655
> > 
> > 
> > In addition, freieFarbe / freeColour provides other colour-related software 
> > for free here: http://freecolour.org/
> > 
> > 
> > 
> > Colour Software Release Planned
> > ===
> > 
> > freieFarbe e.V. / freeColour also intends to release a previously 
> > closed-source colour software product written in RealBasic as Open Source 
> > under a GPL 2+ licence. fF / fC hopes to find contributors who are 
> > interested in porting the code from RealBasic to C++ and Qt, as well as 
> > mergin

Open Colour Systems Collection 2.0 released

[Christoph Schäfer]

Open Colour Systems 2.0 Released


freieFarbe e.V. / freeColour is pleased to announce the release of Open Colour 
Systems Collection (OCSC) 2.0.

Following the release of OCSC 1.0, freieFarbe / freeColour has been been 
recognised by German authorities as a non-profit organisation. The release of 
OCSC is the first one after the official recognition.

OCSC 2.0 comprises ten additional colour palettes. More importantly, it is now 
also available in Adobe's Swatch Exchange Format (ASE), as well as a Plain Text 
Format version with the file extension CLF.

All colours have been measured from vendor-supplied colour references with a 
spectrophotometer.

Since freieFarbe e.V. / freeColour is an advocate of the use of the CIE LAB/HLC 
colour model as a free and reasonable alternative to proprietary colour 
collections, colour values in the palette files are in CIE LAB.

Download


SBZ: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_SBZ.zip
SHA1 checksum: 6b2bab7dde9e5fe9e8778ee9f79f31edcaa8cef8

ASE: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_ASE.zip
SHA1 checksum: fea350149e2b95af55f36e283fe597f279d3f79c

CLF: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_CLF.zip
SHA1 checksum: e65fd94db7f0d6484df9ce0cf0288ecd328ec655


In addition, OCSC 2.0 has been released in three RGB versions for use in 
LibreGraphics programmes that don't support the LAB colour model and/or one of 
the formats listed above (yet). The formats are: GPL (GIMP, Inkscape, Calligra 
Office, Krita, MyPaint), SOC (Apache OpenOffice, LibreOffice, OpenOffice.org), 
and XML (Scribus 1.4.x).

Download


GPL: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_GPL.zip
SHA1 checksum: c0eefb3a74f658c9c201d5671b4af6a085650cbb

SOC: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_SOC.zip
SHA1 checksum: 318d8fbaf391b0ec39fa433e807e3ec658381376

XML: http://freiefarbe.de/wp-content/uploads/2016/12/OCSC_20_ScrXML.zip
SHA1 checksum: da456792dc89445022ab4ae1af3f5ccedc722cd6


A complete package with all supported formats is available here: 
http://dtpstudio.de/downloads/freeware/OCSC_20.zip
SHA1 checksum: e65fd94db7f0d6484df9ce0cf0288ecd328ec655


In addition, freieFarbe / freeColour provides other colour-related software for 
free here: http://freecolour.org/



Colour Software Release Planned
===

freieFarbe e.V. / freeColour also intends to release a previously closed-source 
colour software product written in RealBasic as Open Source under a GPL 2+ 
licence. fF / fC hopes to find contributors who are interested in porting the 
code from RealBasic to C++ and Qt, as well as merging the features of 
Swatchbooker and the original product. The majority of the code is UI-related, 
but the essential algorithms (the core of the product) are well-commented. Any 
assistance with respect to the organisation of the release of the source code 
would be welcome.



About freieFarbe e.V. / freeColour:
===


freieFarbe e.V. / freeColour is a non-profit organisation that was founded in 
2016 by German and Swiss colour professionals after having worked as an 
informal initiative without legal status for several years. our motto is "We 
want to unchain colours". The organisation is looking for cooperation with 
colour experts, software developers and users around the globe who share our 
goals. You are invited to become a member and/or contribute your own project.

freieFarbe e.V. / freeColour is convinced that the design world will benefit 
from truly free colours and better colour software.



December 2016

Holger Everding
Christoph Schäfer

www.freiefarbe.de
www.freecolour.org
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Aw: Re: Please add an option to set bug reports to "Private"

[Christoph Schäfer]

>  wrote:
> > Dear LibreOffice developers,
> >
> >
> > I'd be grateful if you could add an option to your bugtracker to hide bug 
> > reports and/or sample files from public view, i.e., add a "Private" option, 
> > so that only developers and admins can see them.
> 
> The whole world is a potential 'developper' in an open source project.
> That is the whole point.
> 
> If a customer want secrecy and NDAs and the like.. they need to use a
> consulting company to solve their bug. This is the only way they can
> maintain any sort of 'secrecy' of their test documents.
> 
> The only viable alternative, as mentioned  elsewhere in this thread,
> is to sanitize the documents to remove 'sensitive' stuff.
> You cannot expect volunteers to go through hoops to give you free
> support because you are not willing to do your part.
> 
> Norbert
> 

Wow, what a genuinely polite reply! Do you behave like this at home or at work?


Just to be clear, I'm coming from the graphics design and layout community, and 
I want to support the development of libraries like libfreehand or 
libpagemaker. For that purpose I used my contacts to layout and DTP experts and 
asked for sample files, so I could test the importers with all programmes that 
use them, but primarily LibreOffice. In other words, I and the friendly people 
who donated from their backups want to help you to fix YOUR bugs. 


We are no beggars who want you to solve our non-existing problems but do like 
what DLP/LibreOffice is doing and want to support it. Most people who sent me 
their test files probably don't use LibreOffice (yet), and if they do, they 
certainly don't need its graphics/DTP import filters. They do know, however, 
that other projects like Inkscape and Scribus use them.


Since we're talking about graphics design, it's not possible to "sanitise" the 
files for several reasons. First of all, these files have been created as "work 
for hire" and they're design/layout files, so even removing or replacing text 
doesn't change the design or layout as a whole, for which someone has paid a 
few quid. Second, these files have been created with programmes that the 
creators no longer use or no longer have access to. The same goes for operating 
systems like Mac OS 8 or OS/2, and back in the days it could make a huge 
difference whether a file had been created on a Mac or a Windows / OS/2 
platform. 


Also note that the complexity of real-world vector design and DTP files is an 
order of magnitude higher than that of "office" files or bitmap graphics.


I already mentioned that I've been told by an DLP developer that it's not 
enough to send them files directly, because as far they are concerned, bugs 
only exist if there is a bug report. So here we are, on the one hand a growing 
collection of test files that might help to improve the DLP libraries, 
contributed by people who want to support your project, but that also need to 
be treated confidentially. On the other hand a vicious circle of DLP insisting 
on bug reports but the impossibility to upload the respective test files, since 
there is no "Private" option in the bugtracker available.


If someone has an idea how to solve this issue, I'd be glad to hear from the 
community (and I don't mean (c)rude fellows like you, Norbert). 


A suggestion from my side would be to grant DLP hackers "Developer" status on 
Scribus's bugtracker (bugs.scribus.net) for DTP and vector formats, so I can 
upload the test files over there as "Private". As "Developers" they would have 
access to the test files. The status would only be granted if one of the DLP 
leads (e.g. Fridrich Štrba or David Tardon) can confirm that the person is 
indeed an active DLP developer.



Christoph
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Please add an option to set bug reports to "Private"

[Christoph Schäfer]

Dear LibreOffice developers,


I'd be grateful if you could add an option to your bugtracker to hide bug 
reports and/or sample files from public view, i.e., add a "Private" option, so 
that only developers and admins can see them.


The reason for my request is that I have many sample files for the DLP project, 
created by third parties, that show enormous deficiencies in these import 
libraries. I've sent some of them to the developers, but I've been told that, 
as far DLP is concerned, bugs and issues don't exist unless they show up in the 
bugtracker. The advantage of those files is that they have been created by real 
graphics professionals for real customers and are far more valuable than simple 
unit tests. Unfortunately I cannot file bug reports regarding the test files, 
because there is no "Private" option for files that require confidentiality.


The Scribus project is using Mantis as a BT, and we have been successful in 
receiving many real-world test files that helped us fixing bugs with the 
"Private" option.


Maybe you could enable this option in the LibreOffice bugtracker, too, because 
it would definitely help to improve the DLP libraries.


Thanks,
Christoph
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Christoph Schäfer licence statement

[Christoph Schäfer]

All of my past & future contributions to LibreOffice may be licensed under the 
MPLv2/LGPLv3+ dual license, except for test files I contribute to the Document 
Liberation Project, which may have been created and provided by third parties 
and for which I may have no authority to relicense.

Christoph Schäfer
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

libreofficeonline / Problems building loolwsd

[Christoph Schäfer]

Hi all,

trying to get a libreofficeonline dev environment up for the first time. 
Environment:
- Ubuntu 16.04 LTS
- poco-1.7.5
- libreofficeonline 1.9.2

Proceeded like described here: 
https://github.com/LibreOffice/online/tree/master/loolwsd

After starting the build of loolwsd I get the error below. Seems like some 
libs/ headers don’t match but I can’t figure out. Thanks for any pointers.

Best
Chris

—— CONFIGURE ——
./configure --enable-silent-rules --with-lokit-path=${MASTER}/include 
--with-lo-path=${MASTER}/instdir --enable-debug
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1966080
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking for gawk... gawk
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... no
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared 
libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking