summaryrefslogtreecommitdiff
path: root/vcl
AgeCommit message (Collapse)AuthorFilesLines
2015-05-01Resolves: tdf#73211 gtk checkboxes need erase afer togglingCaolán McNamara2-1/+8
because an unchecked checkbox can have a smaller paint area than a checked checkbox. This has always bugged me (cherry picked from commit d194074aa34e3724dd9b93fbc81bf2ba793cd37a) Conflicts: vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx Change-Id: Iac0f075089611b47c381863a9655445d732bfddc Reviewed-on: https://gerrit.libreoffice.org/15510 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2015-04-23tdf#86793: vcl: speed up OutputDevice::GetEllipsisString()Michael Stahl1-1/+2
The ridiculous algrorithm used for TEXT_DRAW_CENTERELLIPSIS will go faster if we cut out most of the text at the beginning instead of one at a time. (regression from 912ecaf565e68d2ca3fb9584712313e712749f75) (cherry picked from commit c6ec3e4cee8c7c22380780f2661ac23946cdb050) Change-Id: I9310dda1847222215bafe372e3efef9d365e1ad9 Reviewed-on: https://gerrit.libreoffice.org/15356 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-04-16tdf#84294: vcl: fix PDF export of transparent Writer frames in LO 4.3Michael Stahl1-0/+1
The transparent frame background is painted opaque because OutputDevice::DrawTransparent() records a MetaTransparentAction instead of returning early. Note that master and 4.4 use drawinglayer to paint backgrounds so the problem is only visible in 4.3. (regression from 36b59f2efc2bfb2c9256c39eb5687808deb) Change-Id: Ide7a076b72123097a9fe099b96d36cda7f7bb082 (cherry picked from commit 581314958f0ddd6c3a0536ce2d7e7e6f0c53a8ec) Reviewed-on: https://gerrit.libreoffice.org/15343 Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2015-04-14Resolves: tdf#86399 don't clobber cluster start caret posCaolán McNamara1-6/+7
with other cluster element bounds (cherry picked from commit b1030f75d3e47719ca63ec518f1da75196bead1a) Conflicts: vcl/source/gdi/sallayout.cxx Change-Id: I2cc976eb6a0ef42a2678be80637c7220e2247921 Reviewed-on: https://gerrit.libreoffice.org/15121 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
2015-04-04fix hang with ooo71962-1.odtCaolán McNamara1-1/+3
script run ends after chunk we are rendering (cherry picked from commit 00bf3a4259c1f960eff05b17649cc734c275950f) Change-Id: Idbfe11c385db72a80d3d204f8638d67395580d1b Reviewed-on: https://gerrit.libreoffice.org/15116 Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com> Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
2015-04-04vcl/text: fix duplicate text in fontwork tdf#81876Pierre-Eric Pelloux-Prayer1-0/+3
Regression introduced by commit 2ba05b4800d6cc322276a6911792363f8eb32051 because space character will take the error code path. The error propagates up to GetTextOutlines which then uses the fallback method. In this case, we now reset any work done before, to avoid having duplicate outlines. Change-Id: Ie15524ac462d4b4bb3c482e49c4fe96a2f2d2c71 Reviewed-on: https://gerrit.libreoffice.org/14850 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 162f11cdb94b415ff9d58674e94fb01a745a69eb) Reviewed-on: https://gerrit.libreoffice.org/14898 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Tested-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2015-04-04Resolves: fdo#86493 Fix crash while scaling large bitmaps.Ashod Nakashian1-6/+7
Fast bitmap scaling overflowed the LUT used by the nearest-neighbor algorithm. When a bitmap has 46k pixel on a side and is enlarged, the scaling code overflows the 32-bit long, resulting in negative indexes, which then segfaults. This isn't as rare as it sounds. At least in web-view in writer the border/shadow bitmap is as long as the document (which is an issue in its own right,) which can overflow for large documents during scaling and segfault. Reviewed-on: https://gerrit.libreoffice.org/14597 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit c91bfb9ac7d110c5dca0ea34ec0e1668a985b34c) Change-Id: I1ccf73d02469f6601a9a7e67b30524cb497cf6bc Reviewed-on: https://gerrit.libreoffice.org/14809 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Miklos Vajna <vmiklos@collabora.co.uk> (cherry picked from commit e40f78753e10be6ca867aac593b6f0be166f3b73) Signed-off-by: Michael Stahl <mstahl@redhat.com>
2015-03-16fdo#52540, fdo#88051: fix Graphite layoutLászló Németh1-2/+5
The previous fixes were incomplete solutions (see the new test cases of the bug reports). Change-Id: I928f09d94edf68d268de9046c16582e6f016d561
2015-03-12Fix crash when timestamping PDF signatureTor Lillqvist1-2/+7
Using the NSS API for CMS and ASN.1-based stuff in general correctly is extremely hard. It is very easy to do things slightly wrong. Of course no compiler warnings are produced. You just get code that happens to work by accident when compiled with one compiler, but not another, or depending on contents of uninitialised memory, or the phase of the moon. The problem was that the "values" field of a NSSCMSAttribute struct apparently is supposed to point to *two* SECItem pointers, one pointing to the actual value, and a NULL one. Anyway, now valgrind finally does not complain about any use of uninitialised memory. Most likely my earlier recent commits to this file were not necessary after all. They just seemed to help by accident, at least at one stage. But whatever... Change-Id: Ic98401b5d151bbb2398f809f47699f670e9720fa
2015-03-12Don't bother with macros that are dummy on Unix in Unix-only codeTor Lillqvist1-11/+5
In NSS's <secasn1t.h>, for non-Windows: #define SEC_ASN1_SUB(x) x #define SEC_ASN1_XTRN 0 #define SEC_ASN1_MKSUB(x) Change-Id: Ie42d881cebffdd060309d6a15d8d9c319c260699
2015-03-11Fix signature overflow check in the NSS caseTor Lillqvist1-11/+11
We didn't actually check this correctly at all, but gladly overwrote the allocated part of the output PDF, thus obviously rendering it invalid. The parameter passed to PORT_NewArea is a default chunk size, not a maximum anything, so it was misleading, even if not wrong as such, to pass MAX_SIGNATURE_CONTENT_LENGTH to it. Use 10000 instead. No need to do the overflow check twice in the Win32 case. Change-Id: Ifa796dbb74b32e857f7184c1e8ada97ba124b020
2015-03-11Move more variables out of the timestamping blockTor Lillqvist1-5/+4
One or more pointers into them apparently gets stored into the NSSCMSMessage data structures during the my_NSS_CMSSignerInfo_AddUnauthAttr() call, and thus when the variables go out of scope said data can and will be reused for some arbitrary other thing, and those pointers in the NSSCMSMessage will point to bogus data. Avoids a crash when compiled with gcc. (No crash when compiled with Clang, it apparently allocates nested block stack variables differently.) (The Windows MSVC build uses a different code path entirely here.) Change-Id: Ic941d766904a216cce86ee6bd38864801b9110e8 (cherry picked from commit 90a684b32b93988e890d854deff384addd875de9)
2015-03-05tdf#88428: Add GUI to select one of user-configured Time Stamp AuthoritiesTor Lillqvist1-2/+4
Work in progress. The selection not used for anything yet. (cherry picked from commit b8b9d51b8cf1cafe1a94e1baf957f3f282abb32f) Conflicts: filter/source/pdf/impdialog.cxx include/sal/log-areas.dox Change-Id: Ia86fa0f59dcfee8e9d332a028a3fad37f4019fe0
2015-03-05tdf#84881: Timestamp the right data (Win32 version)Tor Lillqvist1-107/+241
Now Adobe Reader is satisfied with the signature timestamp also for a PDF signed and timestamped on Windows. My gleeful commit comment from yesterday about how much simpler the Win32 crypto API was to use for this task was not entirely true. It is simpler than using NSS and curl, but not as simple as I had hoped. Oh well, I am not really surprised. I now use the "low-level" message functions instead of the single "simplified" CryptSignMessage(). And just like with NSS, I need to create the message twice; first to get the signature to timestamp, and then a second time to attach the timestamp. But now I wonder whether doing CryptSignMessage() twice would work too. Anyway, won't touch the code now for a while. I am actually a bit surprised that the code works... Must have been my lucky day. Or then I just am good at making educated guesses at what an API does, even if the documentation doesn't make it perfectly clear. Especially, I am a bit surprised that calling CryptMsgGetParam(hMsg, CMSG_BARE_CONTENT_PARAM) returns (just) the signature. OTOH, what else would it return? Change-Id: Iec20c7605cf3d841b9e1787184c7b665837f1bc2 (cherry picked from commit 2c78736c19a8f2a1df0f406c3e92f5ac55576148)
2015-03-05tdf#84881: Timestamp the right data (NSS version)Tor Lillqvist1-2/+4
Now Adobe Reader is satisfied with the signature timestamp. I just need to figure out how to do the corresponding fix for the Win32 version, too. Change-Id: Ie2cce177a9a356e729ca157b4c181e95a2c60c91 (cherry picked from commit ce0e240ef10566f1cc334386dbde83b43ebb9281)
2015-03-05tdf#84881: Add Windows implementation of timestamping of signatureTor Lillqvist1-0/+122
Luckily doable with much simpler code than the horrible NSS and curl mess used on Linux (and, sadly, OS X). Basically only one new API call needed: CryptRetrieveTimestamp(). A few hours of work, compared to about a week for the Linux case. However, amusingly, it causes the same message in Adobe Reader as when using the NSS code: "The signature includes an embedded timestamp but it could not be verified". Sigh. Change-Id: I98c973bd50b841d1ae3feb8a695bac29da538b6c (cherry picked from commit 00646102569739e0bf8929c271963f129d747a5a)
2015-03-05tdf#84881: Try to fix "The signature includes an embedded timestamp but ...Tor Lillqvist1-16/+131
... it could not be verified" I got some insight reading this question and reply on stackoverflow: http://stackoverflow.com/questions/18761993/steps-to-include-timestamp-in-pdf-signature I had been doing the timestamping wrong in the same way: I had timestamped the hash of the PDF document, not of the signature. That is wrong. If you think hard, it is obvious: It is the (rest of the) signature that needs an authenticated timestamp, not the PDF document contents. After all, if the document contents is timestamped, but not the signature, that doesn't prevent tampering with the signature after the timestamping. When you timestamp the signature, that proves the date of the signature. (And the signature proves the authenticity of the document contents.) So I had to re-engineer the code a bit. I create two originally identical NSS CMS messages with signatures, encode one signature into DER, take the hash of the signature, get a timestamp from the TSA for that hash. Then I add that timestamp to the other CMS message as an unsigned attribute of its signature, sign it, encode it, convert to hex, and store it the document. (I first tried to use just one CMS message, but NSS stopped with an assertion when I tried to encode the signature of the same message a second time, after adding the timestamp attribute to the signature. Go figure.) (I did verify the the encoded signatures, taken from what should be identical but separate CMS messages, was in fact identical. So I am fairly sure the idea described above is sound.) But, it doesn't help. Adobe Reader still complains "The signature includes an embedded timestamp but it could not be verified". Change-Id: I4e4cd0443005e82f597586942badc7145ef64160 (cherry picked from commit 86796f127b15fd33374f2a18344dc944b7b8314d)
2015-03-05tdf#84881: Slight refactoring and redordering of function callsTor Lillqvist1-63/+95
No change to functionality or end result. Preparation for an attempt to fix the remaining problem with RFC3161 timestamped signature. Change-Id: I5790a85399e9f94d816e8fab791a03d607113116 (cherry picked from commit 0874849206a38cbe15cc981b6cb814d3a7abf38b)
2015-03-05tdf#84881: Bump MAX_SIGNATURE_CONTENT_LENGTH to 50000 for nowTor Lillqvist1-1/+14
Note that checks in the code against exceeding that limit apparently are broken, though. After the previous change I ended up with an invalid PDF where the signature hex string in the output PDF had brutally overrun its allocation. Now Adobe Reader says "The signature includes an embedded timestamp but it could not be verified". This is progress. Perhaps I just need to tell Adobe Reader to trust the certificate from the TSA I used. (cherry picked from commit ca2d878659400b783ae72267f47d0c719b50a1ad) Conflicts: vcl/source/gdi/pdfwriter_impl.cxx Change-Id: I1e8644ee641592a985e0190b52bf76839f99b3e7
2015-03-05tdf#84881: Set TimeStampReq::certReq to trueTor Lillqvist1-3/+3
I think Adobe Reader expects the timestamp info to include the TSA's certificate. Change-Id: Iedf1c4a9952b12ac61b4ba7f73bee339480e821d (cherry picked from commit 4702f6ae2f671ac48e4cae3cd46d5941d021e533)
2015-03-05tdf#84881: Move some variables one block level outTor Lillqvist1-5/+5
It it scary to keep pointers to stack variables that have gone out of scope in a data structure that is in an outer block and used there later. Change-Id: Iced8b809d50089a4e6f9867be9b8501cce59d16f (cherry picked from commit 5ffeec96228e0adb829612ecb855cd28e2063f1d)
2015-03-05tdf#84881: NSSCMSAttribute::type can't be null. Must be same as typeTag.oid?Tor Lillqvist1-5/+5
Why is a separate field then needed? Dunno, but probably because the type and values fields make up an encoded NSSCMSAttribute. (The comment in <nss/cmst.h> says so, but it took a while before I realized what it meant.) The typeTag and encoded fields are for NSS internal use or something. Now Adobe Reader says "The signature includes an embedded timestamp but it is invalid". Progress... Change-Id: I390947db8d414a7ceecc1f67aaeed5fa0f66fe6f (cherry picked from commit 167569bfea0bfa5f697ed7a25a354537bc97fa53)
2015-03-05tdf#84881: Fix typo in OID string for id-aa-timeStampTokenTor Lillqvist1-1/+1
Not that it seems to help. Adobe Reader still claims "signing time is from the clock on the signer's computer". (Why can't RFCs come with standard C header files (and Java and C# sources) defining macros/constants for the magic numbers, OIDs etc that the RFC defines?) Change-Id: I56e8cb4ef56e20345506a080e4d23764d2dfb956 (cherry picked from commit c98f569d035861b6b8c74b469512fa2ae7c9576f)
2015-03-05SAL_WARNs are not for the end-userTor Lillqvist1-33/+33
They can and should be terse, technical and informative. Simply say exactly what API function call failed. The tag and source file name in the SAL_WARN output should already tell a technical reader of the warning what functionality it is related to. Change-Id: I93509bddaca836bd6a07d2899b3faf693b071957 (cherry picked from commit d1f679cacb2e17c4aa94ae6b9f15011c9ec74b25)
2015-03-05tdf#84881: Call NSS_CMSSignerInfo_AddSigningTime() only if not using a TSATor Lillqvist1-5/+4
Something is still wrong, Adobe Reader still says the PDF is signed with the local machine's timestamp, though. Change-Id: Ic9ed3190901025be48e1de191df976e1aa454822 (cherry picked from commit 7d7c2ab1dffa82cfc0e2d6b15702d965b8b0245b)
2015-03-05tdf#84881: Actually check the status of the time stamp responseTor Lillqvist1-0/+7
Change-Id: If8d64b1e03c8318cd3329cd258131fddeb86fa7b (cherry picked from commit d1132ff3895aa67ed662446ef6f43612124455ae)
2015-03-05Copy SEC_StringToOID() and NSS_CMSSignerInfo_AddUnauthAttr() hereTor Lillqvist1-9/+219
Despite being declared in a public header, they are not exported from libsmime, so copy them here. Sigh. Fix fallout from fe480d8136b204c8dc6c68916cce7e816f8b9c48. Change-Id: I9ecba690a66c263528e5c12738d60cacec4f14ee (cherry picked from commit e075fec6e18b24f4037c11f015e870a470fa8ef8)
2015-03-05tdf#84881: Unclear what the PKIStatusInfo::statusString isTor Lillqvist1-4/+6
Anyway, we can't assume that a string from an external source is correctly formed UTF-8. Change-Id: Ic906c7047b933388d5b51b23095a5a3d4ac7e508 (cherry picked from commit 639730a75294346d4195539c26f466f14d030802)
2015-03-05tdf#84881: Dump also the CMS data in a DBG_UTIL buildTor Lillqvist1-0/+8
Change-Id: I651041a86083eb49aad9a96f6f379149c21854f3 (cherry picked from commit f4f08203ba4acebb4ae3143323ca508fdc0644bd)
2015-03-05tdf#84881: Work in progress: Code to add the timestamp to the signatureTor Lillqvist1-4/+40
Inside #if 0, as the two NSS functions I would want to use aren't exported from libsmime, despite being declared in public headers. Back to the old drawing board. Change-Id: I8b868b4d645a7bbab670e237568c8ff7d97c98cc (cherry picked from commit d1293c666f08963cebb5f1439034dd11634392df)
2015-03-05tdf#84881: Work in progress: Decode the TimeStampRespTor Lillqvist1-33/+294
OMG, it is really horrible to use the NSS SEC_ASN1DecodeItem() API. Figuring out how to set up the SEC_ASN1Template data structure for decoding TimeStampResp was much harder than setting up the template for encoding a TimeStampReq. Luckily I don't actually need to look into the timeStampToken, but can copy that as such into the CMS as an unsigned attribute. I'll cheerfully ignore for now RFC3161's requirements on how the TSA client should check the validity of the response. Let's leave that up to the PDF viewing (and validating) application. Also improve the SAL_INFO logging, use a timeout for the curl operation, add more ASN.1 in comments for information, etc. Still to do: Actually add the TimeStampResp to the NSSCMSSignerInfo. (cherry picked from commit 3cc45e97dd9189b4c76747fce8925bfe48fac70a) Conflicts: vcl/source/gdi/pdfwriter_impl.cxx Change-Id: Id4f800e2cf12a01106b326a31c34eb99f2aa724e
2015-03-05Use curl_easy_strerror() for more information in SAL_WARNTor Lillqvist1-14/+15
Change-Id: I633bd5d697321678d5c179161ac18bc5655246ec (cherry picked from commit 4146b5c3fefcfce10ed6bc7e739408de8acafb92)
2015-03-05tdf#84881: Work in progress: Perform the RFC3161 interaction with the TSATor Lillqvist2-6/+121
Use libcurl to perform the request and get the response. Improve error messages (only use SAL_WARN, though, so sadly not visible to end-users). Still to do: Decode the response and attach it to the signature. Implement request encoding and response decoding for Windows. I probably should extend (and rename) the HashContextScope class to handle all resources that need explicit deallocation, instead of calling curl_slist_free_all(), curl_easy_cleanup() and SECITEM_FreeItem() in so many places. The error handling of the PDF export functionality would need to be re-designed so that we could show actual error messages to the user instead of generic "signing failed" ones. But that is typical for much of our code... Change-Id: I6288de3f09021f8e0f385870143fefffbac2a706 (cherry picked from commit 27d7aea00d22ad3fcdff2e7b267be1cf5c28d43c)
2015-03-05tdf#84881: reqPolicy and certReq are optionalTor Lillqvist1-6/+5
Change-Id: Ia5687bf2d68eef06aeb618d5387c663807d24560 (cherry picked from commit 2ddfaa6d323b5db2f59f06f7708c5209549abeee)
2015-03-05tdf#84881: WiP: Fill in more fields of the TimeStampReqTor Lillqvist1-36/+54
Use the digestAlg in the NSSCMSSignerInfo, once we have it, as hashAlgorithm. Use a random number as nonce. Temporarily, dump the TimeStampReq object to a file for inspection in a DBG_UTIL build. Change-Id: I696271b3ccc6cef86a70bc78f86d6eae27a4af77 (cherry picked from commit 159a4c3c75e3a7aecbf1656f3254331892098ba7)
2015-03-05tdf#84881: WiP: Handle TimeStampReq::extensions correctlyTor Lillqvist1-9/+6
Also, pass dest as NULL to SEC_ASN1EncodeItem(). Now we can call SECITEM_FreeItem(item, PR_TRUE) on its return value. (cherry picked from commit 4ece31faef6279cdb0d7eafa26f696e393649fd4) Conflicts: vcl/source/gdi/pdfwriter_impl.cxx Change-Id: Ia30b70990971aba15158f97528524d879a04da3c
2015-03-05tdf#84881: Intermediate commit: Construct RFC3161 TimeStampReqTor Lillqvist1-1/+159
It took a while to figure out how to use the NSS API to construct ASN.1 DER-encoded data using the SEC_ASN1_Template data structs. But I am getting closer. Now the SEC_ASN1EncodeItem() doesn't crash at least. Change-Id: I863542bbeed47d48d05a67b851648f87ba9ccf31 (cherry picked from commit 4f69b6de069b7ed70a4aa0095ad9bf981eed53ae)
2015-03-05Add plc4 for PL_strdupTor Lillqvist1-1/+2
Change-Id: I2a2f18d76b0deb5f6cfd68b36699d940703372b3 (cherry picked from commit 77d844c9a92fdc1b8ffa043f46ea50bc1cfa7e05)
2015-03-05Tentative fix for fdo#83937Tor Lillqvist1-13/+26
One clear bug in the code, in my opinion, was that PDFSigningPKCS7PasswordCallback() returned its argument as such. However, a PK11PasswordFunc should return "a pointer to the password. This memory must have been allocated with PR_Malloc or PL_strdup", says https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/SSL_functions/pkfnc.html . I could not test this fix fully before my hardware token decided to block itself, thanks to too many wrong PIN attempts. Possibly it would work to even just pass NULL for the password callback function and its argument to NSS_CMSEncoder_Start(). After all, at least with the hardware token and associated software that I tested with, the software itself pops up a dialog asking for the PIN (password). (cherry picked from commit cbf0c9f8332be9abfed6016f9708e3260331eb2d) Conflicts: vcl/source/gdi/pdfwriter_impl.cxx Change-Id: I85a8b2833cfdd1a1d7b7779016fefb71dd53ab80
2015-03-04in BITFIELDS mode (3) there are *3* pal entries not 12Caolán McNamara1-1/+1
There are 12 *bytes*, which presumably is the thinko there. But this nPalCount gets multiplied by 4 to convert it to bytes later. This is the source of the bad mask values found after "Use the cairo-compatible basebmp surface for headless" etc. Arbitrary values ended up being read as mask values. Change-Id: If5d93f74b1c58d3ecdb5186f93cb0215a556586a (cherry picked from commit 5e5b90c12862b522a4553337fbf6309bb8278b8c) Reviewed-on: https://gerrit.libreoffice.org/14660 Tested-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Michael Stahl <mstahl@redhat.com> (cherry picked from commit f20197a5e6da7ab0b550bce7ef2e07b7f7b401d5)
2015-03-04tdf#89666: vcl: speed up HbLayoutEngine line layout for large paragraphsMichael Stahl1-1/+1
When formatting a 180k char Writer paragraph, most of the time is spent in vcl::ScriptRun::next(), which is called twice per line from SwTxtGuess::Guess(), once via GetTxtBreak() and once via GetTxtSize(). In the second call, from GetTxtSize(), the end position of the line is known, and passed to vcl, and iterating beyond that position seems pointless. This reduces vcl::ScriptRun::next() from 24 to 11 billion callgrind cycles when built with GCC 4.9.2 -m32 -Os. (cherry picked from commit 7fde44c85620f8079bc4863fe3f7ea1f69a0f88c) Conflicts: vcl/generic/glyphs/gcach_layout.cxx Change-Id: Ia23fcccaf5ef9c9ecdcb54bfc8f0f8a043c8711e Reviewed-on: https://gerrit.libreoffice.org/14645 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 623f16d7a47020600e2b4ba03aa6a617545b0d93)
2015-03-04tdf#89141: reverted a workaround for getting activity timeVasily Melenchuk1-10/+4
A workaround applied in #i99360 (sha:44e008b01f72c3f02ab3328cdc44f987617f272b) does not works always correctly. This workaround is required to avoid bug in X11 which is already fixed in 2009 (https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/322310). That fix should now be spread enough so there is no reason to keep it. Change-Id: Ied6fe8f32d2da5922092bd9ed47ee56c4f67a255 Reviewed-on: https://gerrit.libreoffice.org/14671 Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 69a80316f7da33e90e1006624466f52af524f1dc)
2015-02-24dump ugly hack working around an ancient libxcb bug (tdf#89141)Luboš Luňák1-8/+1
According to the X protocol log in the bugreport, this timed function sometimes does time out, in which case the timestamp becomes 0, which as user timestamp is interpreted by window managers as "do not focus", which is indeed stupid to ask for just because a call timed out. Especially given that this is broken in principle, as the event is bound to come (barring the more than 5 years old libxcb bug, which must have been such a lame bug that it probably shouldn't even have been worked around, and definitely not unconditionally and permanently). Change-Id: I4d122ea038c0c56b1fda590df13bf119d746fd0a
2015-02-23Resolves: tdf#89252 Fix bold, regular font spacing bug for Graphite fontsMartin Hosken2-9/+13
Change-Id: I31a09fa753ed15e302e5407ce8a0c46f3b13e099 Reviewed-on: https://gerrit.libreoffice.org/14380 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit 0ed14401925d16932ed98bc418d395adac047b39) Reviewed-on: https://gerrit.libreoffice.org/14439 (cherry picked from commit 0c2447648961bc8fa4776f996604fead893e3be4)
2015-02-06Resolves tdf#89129: crash when defining a specific relationshipJulien Nabet1-5/+3
Returns early if comparison matches so you can reduce iterator scope and avoid last test for logging. Cherry-picked from 30f6ec7cfdf63cea265148bbe3a07d8df34e96d5 /usr/include/c++/4.9/debug/safe_iterator.h:168:error: attempt to copy- construct an iterator from a singular iterator. Objects involved in the operation: iterator "this" @ 0x0x7fffffff3a30 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPvNSt9__cxx19986vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = past-the-end; references sequence with type `NSt7__debug6vectorIPvSaIS1_EEE' @ 0x0x7fffffff4088 } iterator "other" @ 0x0x7fffffff3a90 { type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPPvNSt9__cxx19986vectorIS3_SaIS3_EEEEENSt7__debug6vectorIS3_S7_EEEE (mutable iterator); state = singular; references sequence with type `NSt7__debug6vectorIPvSaIS1_EEE' @ 0x0x7fffffff4088 } 4 0x00002aaab193d6e9 in boost::void_ptr_iterator<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<void**, std::__cxx1998::vector<void*, std::allocator<void*> > >, std::__debug::vector<void*, std::allocator<void*> > >, ImplBtnDlgItem>::base (this=0x7fffffff3a90) at /home/julien/compile-libreoffice/libreoffice/workdir/UnpackedTarball/boost/boost/ptr_container/detail/void_ptr_iterator.hpp:121 5 0x00002aaab193d269 in boost::operator==<__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<void**, std::__cxx1998::vector<void*, std::allocator<void*> > >, std::__debug::vector<void*, std::allocator<void*> > >, ImplBtnDlgItem, __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<void**, std::__cxx1998::vector<void*, std::allocator<void*> > >, std::__debug::vector<void*, std::allocator<void*> > >, ImplBtnDlgItem> (l=..., r=...) at /home/julien/compile-libreoffice/libreoffice/workdir/UnpackedTarball/boost/boost/ptr_container/detail/void_ptr_iterator.hpp:179 6 0x00002aaab193c2ca in ButtonDialog::RemoveButton (this=0x7fffffff3d90, nId=1) at /home/julien/compile-libreoffice/libreoffice/vcl/source/window/btndlg.cxx:340 7 0x00002aaad8ed109b in dbaui::ORelationTableView::lookForUiActivities (this=0x317ef30) at /home/julien/compile-libreoffice/libreoffice/dbaccess/source/ui/relationdesign/RelationTableView.cxx:342 Change-Id: Ied45c222c94d2a362075a3b1550b6092aad77c62 Reviewed-on: https://gerrit.libreoffice.org/14325 Reviewed-by: Lionel Elie Mamane <lionel@mamane.lu> Tested-by: Lionel Elie Mamane <lionel@mamane.lu> Reviewed-on: https://gerrit.libreoffice.org/14349
2015-02-06tdf#88051 fix Graphite layout at Linux Libertine G ligature followed by tabLászló Németh1-1/+1
Change-Id: Iecedb87f6329c1cddcaa4cd939b349924e58d256 Reviewed-on: https://gerrit.libreoffice.org/14201 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-02-06rhbz#1177022: vcl: fix PDF embedding of Type 1 fontsMichael Stahl14-23/+79
Problem is that for the "CM Typewriter" font the Width for "space" (32) is exported as 0 instead of 525, which is the correct value in the AFM. The reason is that PDFWriterImpl::emitEmbeddedFont() has various arrays to map from font code points to Unicode code points, and there are duplicate mappings, so the 160->32 mapping overrides 32->32. The PrintFontManager::PrintFont::readAfmMetrics() actually creates a Unicode to font code mapping (which may legitimately be n:1) that is then inverted; add an additional hack to store a set of "preferred" Unicodes so that PDFWriterImpl can pick the right Unicode. Presumably the code that is stored explicitly via "C" or "CH" in the AFM should take priority over more generic mappings. (cherry picked from commit 5183910a90e97cafc3cfaaad40acdaec0b792f6d) Conflicts: vcl/inc/cairotextrender.hxx vcl/inc/salgdi.hxx vcl/inc/textrender.hxx vcl/inc/unx/salgdi.h vcl/source/gdi/pdfwriter_impl.cxx vcl/unx/generic/gdi/cairotextrender.cxx vcl/unx/generic/gdi/salgdi3.cxx Change-Id: Id4205a1cd45ba6a0a5facee1e39f70c3535e7dd4 Reviewed-on: https://gerrit.libreoffice.org/14207 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2015-02-06Resolves: rhbz#1177022 no width set on space glyph with CM Typewriter fontsCaolán McNamara1-9/+18
Change-Id: I0dfb044b8a339fa6c473e42f31fc28c200cd03ea (cherry picked from commit 37dc4bdbf25847c95f1668553dbae3e2dc885816) Reviewed-on: https://gerrit.libreoffice.org/14206 Tested-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-02-06font cache gets broken on adding an embedded fontCaolán McNamara3-8/+38
(cherry picked from commit 20142afafc809890d5e8dcfd4103c46319a488df) Conflicts: vcl/source/gdi/embeddedfontshelper.cxx Change-Id: I665cde5d4c89443238efb283c86277dedf621197 Reviewed-on: https://gerrit.libreoffice.org/14047 Tested-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-02-03Convenient function to compress a Graphic to PNG imageTomaž Vajngerl1-0/+12
Change-Id: I3d30dd4337b6bd3b5b0c7cdf97a8787c4bc37fa3 (cherry picked from commit 3a7e54f5d2020ea1f6f2b27a51f5ca065844837f)
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-27 14:12:53 +0000