ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66229
|
Fri Feb 27 17:25:30 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 2.7.5 | Re: Attachment problems |
Dennis Seitz wrote: |
Apologies if these are known bugs, I'm very busy at the moment but I wanted to post this before I forget:
I'm using Safari on a Mac to make Elog entries.
1) The preview of some pdf attachments in edit mode displays huge areas of white space around each page. I can send examples if you'd like - please email me directly, for some reason I never get email notifications from this forum (and they aren't being tagged as spam, so I don't know where they go).
2) When that happens, the text entry area for ELcode format expands horizontally to match the huge pdf file width. Text without line feeds then doesn't wrap until the huge window width is filled, so I have to scroll horizontally all the time while editing to see what I've written.
3) So I turned off attachment previewing as a workaround (Preview attachments = 0 ). That worked fine by not expanding the entry area, but I noticed some odd behavior. The list of attachments below the text entry area is badly formatted. Here's a screen shot:

I tried to reproduce this with a new entry but the text was formatted properly for that entry.
P.S. While editing this entry, I see that the text area width is again being set by the width of the picture I've attached - try it yourself; if you try to resize your browser window smaller while editing, the text will only wrap until the width of the attachment is reached - the text no longer wraps at smaller widths than the attachment.
|
Your problem 1) is probably caused by ImageMagick. I use that package to convert PDFs to images. If this package estimates the paper size from the PDF incorrectly, you're screwed. You can go and actually locate the thumbnail pictures in the ELOG directory (should be named xxxxxx_yyyyyy_<name>-0.png). If you check these pictures, they are probably already huge.
Problem 3) indeed is a small bug in elogd, which I fixed in revision #2178. If you can download the SVN version and recompile elogd, you should be fine:

|
66230
|
Fri Feb 27 20:52:42 2009 |
| Dennis Seitz | denseitz@comcast.net | Bug report | Mac OSX | 2.7.5 | Re: Attachment problems |
Stefan Ritt wrote: |
Dennis Seitz wrote: |
Apologies if these are known bugs, I'm very busy at the moment but I wanted to post this before I forget:
I'm using Safari on a Mac to make Elog entries.
1) The preview of some pdf attachments in edit mode displays huge areas of white space around each page. I can send examples if you'd like - please email me directly, for some reason I never get email notifications from this forum (and they aren't being tagged as spam, so I don't know where they go).
2) When that happens, the text entry area for ELcode format expands horizontally to match the huge pdf file width. Text without line feeds then doesn't wrap until the huge window width is filled, so I have to scroll horizontally all the time while editing to see what I've written.
3) So I turned off attachment previewing as a workaround (Preview attachments = 0 ). That worked fine by not expanding the entry area, but I noticed some odd behavior. The list of attachments below the text entry area is badly formatted. Here's a screen shot:

I tried to reproduce this with a new entry but the text was formatted properly for that entry.
P.S. While editing this entry, I see that the text area width is again being set by the width of the picture I've attached - try it yourself; if you try to resize your browser window smaller while editing, the text will only wrap until the width of the attachment is reached - the text no longer wraps at smaller widths than the attachment.
|
Your problem 1) is probably caused by ImageMagick. I use that package to convert PDFs to images. If this package estimates the paper size from the PDF incorrectly, you're screwed. You can go and actually locate the thumbnail pictures in the ELOG directory (should be named xxxxxx_yyyyyy_<name>-0.png). If you check these pictures, they are probably already huge.
Problem 3) indeed is a small bug in elogd, which I fixed in revision #2178. If you can download the SVN version and recompile elogd, you should be fine:

|
Thanks for the bug fix, we'll get our installation updated ASAP. And I will look into why some of my pdf file image sizes are interpreted incorrectly by ImageMagick, it might having something to do with how I've generated them.
Is it possible to set the default image size to always scale to fit the browser window? For example, this entry has a png attachment, but it still suffers from the fact that the text window size is set by the width of the png image.
If I'm forgetting something, sorry, I'm writing in a hurry!
Dennis |
67592
|
Tue Oct 29 12:04:44 2013 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Linux | 2.9.2-2455 | Re: Attachment file names encoding |
Alexander Nozik wrote: | Hello,
I am trying to move elog from old FreeBSD system to a new Ubuntu server and stuck with attachment encoding problem. The elog entries as well as attachments ашду тфьуы are mostly in koi8-r or cp1251 encoding. While it is relatively easy to configure log entries to display correctly, I still can't manage to deal with attachments. In old elog all attachments with Cyrillic file names are "not found" by elog web interface while files are present in the directory (though previous admin could have done something with the encoding).
If I am creating a new elog with default koi8-r charset, then new cyrrilic attachments are uploaded and displayed normally but after download the file name encoding is broken. Does elog do something with attachment name encoding? |
You should be able to figure this out:
As an administrator you can have a look what are the real file names on the file system.
With your browser you can see what are the names of the attachment. Like in this forum, the entry https://midas.psi.ch/elogs/Forum/67571 has an attachment https://midas.psi.ch/elogs/Forum/131008_181353/import.xml
If the two match you don't have an encoding but some file system problem. If they don't match, then we are one step further in solving your problem 
Thought, the file name in the URL has to be URL encoded (see e.g. http://www.w3schools.com/tags/ref_urlencode.asp), which is of course different from the encoding of the file system. |
67593
|
Wed Oct 30 10:15:13 2013 |
| Alexander Nozik | altavir@gmail.com | Question | Linux | 2.9.2-2455 | Re: Attachment file names encoding | Thank you for reply.
I am not very experienced linux user so it could be a problem with the file system. Let me just describe what I do and what I see as a result.
I created a new elog just for the testing purpose, it has "Charset = koi8-r" line in the config file. Than I post a new entry to this elog with russian text and a file with russian file name from windows (so I expect that charset is cp1251). Now I open this entry. The text is fine and the filename is fine on the page (the same russian text I expect to see), but when I try to download it, the actual file name is broken and to restore it I need koi8-r -> cp1252 transformation. The file itself is readable.
If I look in the actual logbook directory, then in the entry file the file name is readable (entry file encoding is koi8-r), but the attachment file name contains many "?" and not readable by file system.
So first my question is what happened to the file name incoding in a logbook directory, and the second one: what should I do to make attachments download as they were uploaded?
Thank you in advance. |
711
|
Wed Sep 29 01:28:22 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | | Re: Attachment file "" empty or not found | That problem has been fixed in 2.5.4-5 |
66777
|
Mon Mar 22 08:58:47 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.7.8-2278 | Re: Attach multiple (many!) files at one time |
Eric Feng wrote: |
Hi,
Is it possible to attach multiple files at one time? Right now I have to attach each individually, click submit, then confirm, then re-select the next file...
This is a pain if one is attaching many files as I often want to do. It would be nice to be able to select groups of files together using Ctrl and/or Shift, and even to attach a whole directory recursively.
I looked through previous threads but did not find this question asked there.
Thanks,
Eric
|
This is a well known problem, but unfortunately it's a limitation of HTML and how web browsers work. If it would be easy to attach whole directories to HTML forms, it would be too easy to steal important files from your computer. So the HTML designers decided that each file hast to be confirmed manually, and that's why you have to click so often. There is no way ELOG could bypass this scheme. |
66781
|
Tue Apr 6 00:45:10 2010 |
| Eric Feng | ericjfeng@gmail.com | Question | All | 2.7.8-2278 | Re: Attach multiple (many!) files at one time |
Stefan Ritt wrote: |
Eric Feng wrote: |
Hi,
Is it possible to attach multiple files at one time? Right now I have to attach each individually, click submit, then confirm, then re-select the next file...
This is a pain if one is attaching many files as I often want to do. It would be nice to be able to select groups of files together using Ctrl and/or Shift, and even to attach a whole directory recursively.
I looked through previous threads but did not find this question asked there.
Thanks,
Eric
|
This is a well known problem, but unfortunately it's a limitation of HTML and how web browsers work. If it would be easy to attach whole directories to HTML forms, it would be too easy to steal important files from your computer. So the HTML designers decided that each file hast to be confirmed manually, and that's why you have to click so often. There is no way ELOG could bypass this scheme.
|
Hi Stefan,
Okay thanks for letting me know. That is unfortunate now.
Is there no way also to select multiple files with shift or ctrl? Is there any usable workaround that you can see?
Thanks,
Eric |
996
|
Fri Mar 18 13:36:19 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | 2.5.6 | Re: Asing a user to an log | > I'm looking for an option to attach a user to a log?
>
> For example:
>
> Rob is making the log, and whant's to dedicate the log to a stagaire,
> the stagiare recieves an E-mail so that he can do the job?
>
> Bud we all want recieve the mail bud the stagiare see's that the job is for
> him.
Maybe use an attribute for that?
Like
Attributes = Author, ..., stagaire
Options stagaire = Jim, Joe, ...
So Rob can select a stagaire from the list, and the email contains this name.
- Stefan |
|