Re: richedit: Documented paragraph border widths are in points not pixels.
Dylan Smith wrote:
The border widths documented by msdn are in points which are 72 dpi, which is not equivalent to pixels (normally 96 dpi). I pre-converted all the border widths to 96 dpi resolution since this avoids needed to store fractions, and often avoids the need for convertion to the displays resolution. --- dlls/riched20/editor.h | 2 +- dlls/riched20/paint.c | 57 ++++++++++++++++++++++------------------------- dlls/riched20/wrap.c | 2 +- 3 files changed, 29 insertions(+), 32 deletions(-)
------------------------------------------------------------------------
Dylan: git apply complains about whitespace errors: 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:10: trailing whitespace. int ME_GetParaBorderWidth(ME_Context *c, int flags); 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:35: trailing whitespace. /* The documented widths are in points (72 dpi), but converting them to 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:36: trailing whitespace. * 96 dpi (standard display resolution) avoids dealing with fractions. */ 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:37: trailing whitespace. static const struct {unsigned width : 8, pen_style : 4, dble : 1;} border_details[] = { 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:38: trailing whitespace. /* none */ {0, PS_SOLID, FALSE}, error: patch failed: dlls/riched20/editor.h:229 error: dlls/riched20/editor.h: patch does not apply error: patch failed: dlls/riched20/paint.c:461 error: dlls/riched20/paint.c: patch does not apply error: patch failed: dlls/riched20/wrap.c:522 error: dlls/riched20/wrap.c: patch does not apply Current git as of this morning. James McKenzie
On Sun, Feb 28, 2010 at 1:09 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
git apply complains about whitespace errors: 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:10: trailing whitespace. int ME_GetParaBorderWidth(ME_Context *c, int flags); 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:35: trailing whitespace. /* The documented widths are in points (72 dpi), but converting them to 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:36: trailing whitespace. * 96 dpi (standard display resolution) avoids dealing with fractions. */ 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:37: trailing whitespace. static const struct {unsigned width : 8, pen_style : 4, dble : 1;} border_details[] = { 0001-richedit-Documented-paragraph-border-widths-are-in-p.patch:38: trailing whitespace. /* none */ {0, PS_SOLID, FALSE}, error: patch failed: dlls/riched20/editor.h:229 error: dlls/riched20/editor.h: patch does not apply error: patch failed: dlls/riched20/paint.c:461 error: dlls/riched20/paint.c: patch does not apply error: patch failed: dlls/riched20/wrap.c:522 error: dlls/riched20/wrap.c: patch does not apply
That is weird. It seems like there are dos line ending ("\r\n") in the patch when I download it from gmail, but when I save the patch through alpine it has unix file endings ("\n"). I have been using git imap-send to upload the patch from gmail's draft folder so that I could send manually after looking over everything, but all the text piped into git imap-send has unix line endings. I am not sure if gmail is changing the line endings on me, or if git imap-send is changing line endings when I upload the patch. Either way Julliard must have managed to deal with this since the last patches that I sent were sent in the same way. Has anyone else been having the same problems? $ git --version git version 1.6.3.3 I am using Ubuntu's git package that I recompiled with ssl support for git imap-send (see Ubuntu bug #432786 https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/432786)
On 02/28/2010 02:01 PM, Dylan Smith wrote:
I have been using git imap-send to upload the patch from gmail's draft folder so that I could send manually after looking over everything, but all the text piped into git imap-send has unix line endings. I am not sure if gmail is changing the line endings on me, or if git imap-send is changing line endings when I upload the patch. Either way Julliard must have managed to deal with this since the last patches that I sent were sent in the same way.
I'd be very surprised if git is modifying your patches without telling you. It's probably Gmail trying to be clever. Telling git-imap-send to send as an attachment (--attach) might fix the issue. Or, if you're already doing that, maybe turning it off would fix it ;) git-apply can be configured to automatically fix whitespace errors, which is probably what Julliard is using. Andrew
--- On Sun, 28/2/10, Andrew Eikum <andrew(a)brightnightgames.com> wrote:
I'd be very surprised if git is modifying your patches without telling you. It's probably Gmail trying to be clever. Telling git-imap-send to send as an attachment (--attach) might fix the issue. Or, if you're already doing that, maybe turning it off would fix it ;)
I don't know how others use gmail - but I have had problems using patches coming out of 'Save as' from gmail's web front end with that sort of problem (and the same patch e-mail arriving at my other imap/pop3 account doing okay), until I found the 'show original' tab under gmail's menu selections. Also, there is an -l option for GNU patch to cope with extra white spaces.
On Sun, Feb 28, 2010 at 3:16 PM, Andrew Eikum <andrew(a)brightnightgames.com> wrote:
I'd be very surprised if git is modifying your patches without telling you. It's probably Gmail trying to be clever. Telling git-imap-send to send as an attachment (--attach) might fix the issue. Or, if you're already doing that, maybe turning it off would fix it ;)
I always use --attach because gmail will word wrap to ~80 characters for plain text email. I believe you are probably right about this being a gmail rather than git issue, since I get the same problem trying to send upload drafts through thunderbird, or send emails through alpine using gmail's imap and smtp servers. Conversely I am able to send emails without line ending conversion by manually attaching files through gmail's web interface. I didn't have this issue before when I was using libgmail, but I switched to git imap-send when libgmail was removed from ubuntu's repository. As a result I don't know if gmail's imap/smtp servers just started doing this.
participants (4)
-
Andrew Eikum -
Dylan Smith -
Hin-Tak Leung -
James McKenzie