Re: Attachments (again), posted by David Pilgram on Tue Sep 6 12:39:39 2011
|
> > I wondered if there had been some flag for the config file whereby the original file for attachment was
> > processed by ImageMagick, but not stored, only the .png file(s) stored - or rather, some other way that achieved
> > the same end. as there is no such flag at present.
> >
> > For now, anyway, I can attach the documents/pics I want, then go in and delete the 'originals' as saved in the
> > logbook, leaving just the .png files. But maybe something for the wishlist?
>
> At least I now understood your problem :-)
>
> You can have a script in your hidden logbook, that processes your attachments with "execute new", create thumbnails
> of them (using ImageMagicks "convert") and submit those thumbnails as one additional entry to your public logbook.
>
> But then you would get thumbnails of all attachments of the hidden logbook in the public one, maybe you don't want
> that either? If you want them all, this method is more automated. If you just want some, do it as you suggested it.
>
> In my opinion this is a rather exotic feature request :-)
> I wonder if there is a second person in the world who could use it?
Hi Andreas,
True, as a feature explained here, it may not be the most frequently used ;-)
And you are right, I would not want *all* attachements in the hidden directory to appear in the public. But I've got
quite used to playing around in the logbook subdirectories now.
In my case, the ever-expanding use I make of ELOG - and the fact that I use it with the logbook directory stored on a
memory stick (to move from location to location and use local computers, and that's partly to ensure the hidden
directory stays hidden!) - does mean I sometimes run into issues that some hyper-networked system with ZB of storage
don't even notice. |
|
Re: Attachments, posted by Stefan Ritt on Thu Feb 12 16:54:27 2009
|
| Steve Williamson wrote: |
|
Also, on attachments, if I click on the attachment icon (paperclip) on the list page the URL encodes "/" as "%2f", e.g.
http://xxx.xxx.xxx.xxx:8080/Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc and I get the following error:
"Invalid URL: Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc" . If I then change all occurrences of "%2f" to "/" the link works.
|
You have an old version of elog, this bug has been fixed some time ago. Have a look for example at https://midas.psi.ch/elogs/Linux+Demo/.
If you click on a peperclip there, the attachment is shown correctly. |
|
Re: Attachments, posted by Steve Williamson on Tue Feb 17 12:28:19 2009
|
| Stefan Ritt wrote: |
|
| Steve Williamson wrote: |
|
Also, on attachments, if I click on the attachment icon (paperclip) on the list page the URL encodes "/" as "%2f", e.g.
http://xxx.xxx.xxx.xxx:8080/Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc and I get the following error:
"Invalid URL: Change_Log/..%2FChange_Log%2F090205_123135%2FCHANGE_CONTROL_NOTICE_050209.doc" . If I then change all occurrences of "%2f" to "/" the link works.
|
You have an old version of elog, this bug has been fixed some time ago. Have a look for example at https://midas.psi.ch/elogs/Linux+Demo/.
If you click on a peperclip there, the attachment is shown correctly.
|
Thanks - just downloaded and compiled the latest version and all is well |
Re: Attachment problems, posted by Stefan Ritt on Fri Feb 27 17:25:30 2009 
|
| 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:
|
|
Re: Attachment problems, posted by Dennis Seitz on Fri Feb 27 20:52:42 2009
|
| 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 |
|
Re: Attachment file names encoding, posted by Andreas Luedeke on Tue Oct 29 12:04:44 2013
|
| 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. |
|
Re: Attachment file names encoding, posted by Alexander Nozik on Wed Oct 30 10:15:13 2013
|
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. |
|
Re: Attachment file "" empty or not found, posted by Stefan Ritt on Wed Sep 29 01:28:22 2004
|
That problem has been fixed in 2.5.4-5 |
|