1. 18 Ara, 2015 4 kayıt (commit)
    • Tor Lillqvist's avatar
      tdf#95054: Make sure glyphs alpha blend properly in the Graphite+OpenGL case · ac04051a
      Tor Lillqvist yazdı
      The problem apparently was that the GraphiteWinLayout::DrawTextImpl()
      function drew each glyph using a separate call to ExtTextOutW().  That
      mishandled anti-aliased glyphs (alpha), somewhat in the way as
      described in the nice long comment (thanks kendy!) in
      WinLayout::DrawText().
      
      The irony here is that in the case of Graphite fonts and OpenGL, it is
      exactly from that code block in WinLayout::DrawText() that
      GraphiteWinLayout::DrawTextImpl() gets called, and in that situation
      it itself runs into the same or similar problem as the calling code
      wants to avoid for the run as a whole. It draws each glyph separately,
      and subsequent glyphs will overwrite the rightmost pixels of the
      earlier one instead of blend properly. Or something like that.
      
      As a solution, change the interface of DrawTextImpl() so that instead
      of being called once to draw a run of text, it might draw just a part
      of the run, and in that case expects to be called repeatedly to draw
      the whole text.
      
      The GraphiteWinLayout::DrawTextImpl() implementation does it like this
      in the case of using OpenGL (as indicated by the presence of a
      non-null pRectToErase, as added in
      b7842c93 for tdf#95648). The end
      result is that it draws one glyph at a time into the DC for the bitmap
      allocated in the caller, WinLayout::DrawText(). The caller uses that
      bitmap as a texture and blends it into the actual destination,
      separately for each glyph.
      
      For non-Graphite fonts, or when not using OpenGL, nothing should
      change. No repeated DrawTextImpl calls are done to iterate over a run.
      
      Change-Id: Ib7adc30665fc7804913fd2f8886c5b29d9ca42c4
      (cherry picked from commit 61085083)
      ac04051a
    • Eike Rathke's avatar
      tdf#96366 disable treeview results until fix available · 6e80c6b9
      Eike Rathke yazdı
      Since f82d89f3 EditThisFunc() and
      EditNextFunc() are used to iterate through the formula to obtain
      expression results to display in the treeview. Calling the Edit...()
      functions spoils about everything as it messes around with the edit
      state. As the name suggests..
      
      Change-Id: I8b35d85b7bbf8821b5a995e84f9dd88a0f6f00b9
      (cherry picked from commit 8217ddbf)
      6e80c6b9
    • Yousuf Philips's avatar
      Update hardware/OS info in About dialog · 1ea4a61d
      Yousuf Philips yazdı
      Change-Id: I2c70e88cfa2663d0b3db48c309d7cf1630bbddbd
      Reviewed-on: https://gerrit.libreoffice.org/20632Reviewed-by: 's avatarMichael Meeks <michael.meeks@collabora.com>
      Tested-by: 's avatarMichael Meeks <michael.meeks@collabora.com>
      (cherry picked from commit 52856b6e)
      Reviewed-on: https://gerrit.libreoffice.org/20635Reviewed-by: 's avatarjan iversen <jani@documentfoundation.org>
      Tested-by: 's avatarjan iversen <jani@documentfoundation.org>
      1ea4a61d
    • Eike Rathke's avatar
      Function Wizard shoots itself in the foot · ab28a080
      Eike Rathke yazdı
      Currently the Function Wizard is broken in that editing a function call
      as argument within another function's parameter leads to selections
      being reset and mismatching argument/function information being
      evaluated. Not sure yet what's going on there, but at least don't access
      vectors out-of-bounds or crash.
      
      Change-Id: I633c775556a0b90278d22d0f74d2975c20a08a5d
      (cherry picked from commit 88f3c8f9)
      ab28a080
  2. 17 Ara, 2015 5 kayıt (commit)
  3. 16 Ara, 2015 6 kayıt (commit)
  4. 15 Ara, 2015 25 kayıt (commit)