Re: elog's image manipulation of .png file generated from a pdf/jpg, posted by Stefan Ritt on Mon Feb 11 14:21:05 2013
|
> Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
> But, this is elog v2.9.0-2435, and I am using v2.9.2-2475. And I remember there was a recent issue about the image manipulation at some point, so I went to the
> download section to read the subversion listing to find where this occurred. But you've changed subversion! I couldn't find my way around it, so I not only could
> I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
>
> As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it. Do you know when this was? Could it be relivent?
I upgraded to V2.9.2, so please try again.
/Stefan |
Re: elog's image manipulation of .png file generated from a pdf/jpg, posted by Martin Rongen on Tue Jul 16 15:42:30 2013
|
> > Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
> > But, this is elog v2.9.0-2435, and I am using v2.9.2-2475. And I remember there was a recent issue about the image manipulation at some point, so I went to the
> > download section to read the subversion listing to find where this occurred. But you've changed subversion! I couldn't find my way around it, so I not only could
> > I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.
> >
> > As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it. Do you know when this was? Could it be relivent?
>
> I upgraded to V2.9.2, so please try again.
>
> /Stefan
I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc... |
Re: elog's image manipulation of .png file generated from a pdf/jpg, posted by Stefan Ritt on Tue Jul 16 16:35:01 2013
|
> I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc...
Have you tried on the Demo logbook on the PSI server or on your installation. I just attached an image to this entry, rotated it twice, reduced its size
and it works fine. The point is that I have to reproduce your bug in order to fix it, but it seems I cannot.
/Stefan |
Re: elog's image manipulation of .png file generated from a pdf/jpg, posted by Andreas Luedeke on Fri Jul 19 14:03:29 2013
|
> > I can confirm this bug in V2.9.2. Also after submitting the entry, the orginal image is being displayed, with no rotation, resizing etc...
> Have you tried on the Demo logbook on the PSI server or on your installation. I just attached an image to this entry, rotated it twice, reduced its size and it works fine. The point is that I have to reproduce your bug in order to fix it, but it seems I cannot.
> /Stefan
Hi Stefan,
I've noted that you did your test with a PNG while he was reporting about a problem with a PDF. I'll give it a try with your server
⇄
Detect language » English
It appears to work nicely.
I would suggest that the reporters of the issue add a little bit of information, like the version of the operating system, of ImageMagick and if the problem occurs with only a specific browser, etc.
Regards
Andreas
⇄
Detect language » English
Cool: while it worked fine when I've created the entry, it stops working when I EDIT the entry that had been rotated! Actually it sometimes works and sometimes not.
As a workaround you can always go to "1:1" and then retry to rotate. That worked here.
Andreas
⇄
Detect language » English
⇄
Detect language » English
PS: I've noticed that the thumbnail PNG file only updated in the List view after I did a reload. I'm using Firefox 10.0.11 ESR on SL6.0. |
Re: elog's image manipulation of .png file generated from a pdf/jpg, posted by Martin Rongen on Mon Jul 22 14:05:48 2013
|
Andreas Luedeke wrote: |
I would suggest that the reporters of the issue add a little bit of information, like the version of the operating system, of ImageMagick and if the problem occurs with only a specific browser, etc.
⇄
Detect language » English
⇄
Detect language » English
PS: I've noticed that the thumbnail PNG file only updated in the List view after I did a reload. I'm using Firefox 10.0.11 ESR on SL6.0.
|
Hi all
Tested browsers on my SL6.4 desktop computer are Firefox 17.07, Konqueror 4.3.4. Here the rotation and rescaling is all wonky and the changes are not saved when submitting the entry.
On my Android mobile phone (Chrome 28.0.1500.64) the images rotate and rescale nicely, but the changes are not saved aswell. I tried to force reloading and clearing my cache with all of the browsers.
The elogs I tested are served from Ubuntu 10.04.4 LTS and Debian 3.2.46-1 x86_64 running IM 6.5.7-8 and 6.7.7-10 respectively.
Martin |
Re: elog utility for submission used wrong 'Host:' in POST header, posted by Emiliano Gabrielli on Tue Jul 12 10:15:30 2005
|
> The 'elog' utility for commandline submission used wrong 'Host:' in POST header.
> The host listed after 'Host:' should be the host where the server runs, not the
> localhost (see patch below).
>
> $ diff -u elog.c_20050711 elog.c
> --- elog.c_20050711 Mon Jul 11 18:54:20 2005
> +++ elog.c Mon Jul 11 18:55:31 2005
> @@ -421,7 +421,7 @@
> sprintf(request + strlen(request), "%s/%d?cmd=download", experiment, message_id);
> strcat(request, " HTTP/1.0\r\n");
>
> - sprintf(request + strlen(request), "Host: %s\r\n", host_name);
> + sprintf(request + strlen(request), "Host: %s\r\n", host);
> sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
>
> first = 1;
> @@ -872,7 +872,7 @@
> strcat(request, " HTTP/1.0\r\n");
>
> sprintf(request + strlen(request), "Content-Type: multipart/form-data; boundary=%s\r\n", boundary);
> - sprintf(request + strlen(request), "Host: %s\r\n", host_name);
> + sprintf(request + strlen(request), "Host: %s\r\n", host);
> sprintf(request + strlen(request), "User-Agent: ELOG\r\n");
> sprintf(request + strlen(request), "Content-Length: %d\r\n", content_length);
This is not completally true IMHO .. better, it is, but it is not the only problem.
Elog seems to speak HTML/1.0, where "host:" is not implemented ... Since ELOG does not support Vhosts I think the right beaviour is to remove the "Host:" header at all ...
On the other hand it should replay with an error when a bogus client tries to speak HTML/1.0 specifing "host:",
and (the wrost case) when the bogus client says to speak HTML/1.1 and doesnt provide the required "Host:" header ...
Yes .. elog will ignore it, but it is an RFC requirement for HTML/1.1 ! |
Re: elog utility for submission used wrong 'Host:' in POST header, posted by Stefan Ritt on Wed Jul 20 21:03:29 2005
|
Emiliano Gabrielli wrote: | This is not completally true IMHO .. better, it is, but it is not the only problem.
Elog seems to speak HTML/1.0, where "host:" is not implemented ... Since ELOG does not support Vhosts I think the right beaviour is to remove the "Host:" header at all ... |
So I remove the Host: ... line at all, I hope this is ok with everybody. |
Re: elog submit without user and password, posted by Stefan Ritt on Tue Jul 9 10:58:18 2002
|
> With elog it is possible to submit messages to a password protected
> logbook without specifying the -u option. I.e. NO PASSWORD is
> necessary to submit a message. I assume it is related to the problem
> of expiring password-cookies while entering the message using a web
> browser.
Indeed this problem is related to the expiring password cookies. As a
reminder: For the submission of a new entry, the password is checked when one
presses the "New" button, but NOT for the "submit". This is because a
password can expire between the "New" and the "Submit", so a entered message
could not be sent. The question is now what to do with the standalone "elog".
Right now, elog does a normal submission where the password is not checked,
which is maybe not what one wants. But what to do? If elog sends a special
flag "please do check password on submit", someone could analyze the source
code, remove the flag from elog and then still submit messages without a
password. If I put an additional flag to the web browser submission "please
do not check the password since the cookie might have been expired", someone
can add this flag into elog and still bypass the password checking.
Anothe thing which bothers me is if you specify the password explicitly on
the command line of elog, it's visible in some scripts etc, which yould be a
security issue as well.
Any ideas? |
|