Is there any way to include the text of a log message in the CSV export? 
Anyway to include a pointer to the attachment?

> Is there any way to include the text of a log message in the CSV export? 
> Anyway to include a pointer to the attachment?

The text of a log message is usually several lines long. To my knowledge, CSV
only allows single line values, that's why I excluded the text field from the
CSV export. This is different in the XML export, which supports multi-line
values. If you teach me however how multi-line values can be represented in
CSV format, I could easily add that.

As for the attachment, do you just need a name, or a URL back to the logbook?
Should the pointer be in the form "http://elog.server/logbook/attachment.jpg"
or in HTML form like <a href="http:/...">attachment</a> ?

> > Is there any way to include the text of a log message in the CSV export? 
> > Anyway to include a pointer to the attachment?
> 
> The text of a log message is usually several lines long. To my knowledge, CSV
> only allows single line values, that's why I excluded the text field from the
> CSV export. This is different in the XML export, which supports multi-line
> values. If you teach me however how multi-line values can be represented in
> CSV format, I could easily add that.
> 
> As for the attachment, do you just need a name, or a URL back to the logbook?
> Should the pointer be in the form "http://elog.server/logbook/attachment.jpg"
> or in HTML form like <a href="http:/...">attachment</a> ?

I will attempt to use an active x script in a DTS package on SQL Server to parse
the xml and load it into the database. I can see where CSV has it's limitations.

I searched and found some problems people were having compiling it on Solaris.
However I didn't see anything else.

If your using it, was it hard to get it installed and working?

I've got it running for two years now on a Sun Netra box running Solaris 9

> I searched and found some problems people were having compiling it on Solaris.
> However I didn't see anything else.

I just used the compile instructions as shown in the elog admin manual

Here the Makefile I used

#
# Simple makefile for elogd
#
# S. Ritt, May 12th 2000
# install/clean section by Th. Bullinger, Apr. 26th, 2002
#
# add "-DHAVE_CRYPT" and "-lcrypt" to use crypt() function
#

CC = gcc
LIBS =
CFLAGS = -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket
#CFLAGS = -g -O
EXECS = elog elogd elconv
DESTDIR = /usr/local/bin
SDESTDIR = /usr/local/sbin
MANDIR = /usr/local/man

INSTALL = /usr/bin/install
RM = /bin/rm

ifeq ($(OSTYPE),solaris)
CC = gcc
#LIBS = -lsocket -lnsl
#CFLAGS =
INSTALL = /usr/ucb/install
RM = /usr/bin/rm
endif

ifeq ($(OSTYPE),darwin)
CC = cc
endif

all: $(EXECS)

%: src/%.c
        $(CC) $(CFLAGS) -o $@ $< $(LIBS)

install: $(EXECS)
        $(INSTALL) -m 0755 -o bin -g bin elog elconv $(DESTDIR)
        $(INSTALL) -m 0755 -o bin -g bin elogd $(SDESTDIR)
        $(INSTALL) -m 0644 man/elog.1 man/elconv.1 $(MANDIR)/man1/
        $(INSTALL) -m 0644 man/elogd.8 $(MANDIR)/man8/

clean:
        -$(RM) *~ $(EXECS)


> If your using it, was it hard to get it installed and working?

Not at all.
Just read the manual and it just works.
If you are having problems just read this "forum" the get the answers.

If you have a space in a logbook name and you enable password list, then 
the "List" menu option forces you to the login page each time.
The URL says "aaa+bbb", but when you do not have passwords enabled, the 
URL is "aaa bbb"

> If you have a space in a logbook name and you enable password list, then 
> the "List" menu option forces you to the login page each time.
> The URL says "aaa+bbb", but when you do not have passwords enabled, the 
> URL is "aaa bbb"

Thanks for reporting this. I fixed it in the current CVS version.

There is a problem with the 'Show Attributes' option
causing the 'Format ...' options to be ignored.

See attachment for patch.

> There is a problem with the 'Show Attributes' option
> causing the 'Format ...' options to be ignored.
> 
> See attachment for patch.

Thanks a lot. I applied your patch and committed the changes to CVS.

Hi

We have setup a elog server and would like to import a bunch of emails as
elog entries. Is there some way we can do this ? Since there are hundreds of
emails, it is not possible to post them individually as new elog entries.

Many thanks,
Anand.

Have a look at http://midas.psi.ch/elogs/Contributions/10

I'm configuring this great application in order to replace the previous
elogbook my community is using (in the accelerator's world).

One of the main and mandatory feature they cannot renunce is the possibility
of displaying every attached image just inline, without having to click over
the file name or to enter the entry view (in which the attachment can
already be displayed inline) ...  

- images (and hopefully ps, eps, pdf) be displayed inline just after the
text body of the message in the main "List" view
- possibility to configure the scale of this view
- possibility of build some thumbs in order to save BW and time


Is there any way to do it or any plan to implement such a feature in the
very next future ? 

> One of the main and mandatory feature they cannot renunce is the possibility
> of displaying every attached image just inline, without having to click over
> the file name or to enter the entry view (in which the attachment can
> already be displayed inline) ...  

Displaying images in the list view is possible by going to the "Find" page and
checking "Display full entries" and "Show attachments". This can even be
automatized by putting

Start page = ?mode=full&attach=1

into the configuration file. 

> - images (and hopefully ps, eps, pdf) be displayed inline just after the
> text body of the message in the main "List" view

PS, EPS and PDF files cannot be displayed inline by the browser (at least not
the browsers I know). I guess what you want is that users submit PDFs, and elog
should convert the PDF automatically into JPG and display a reduced version of
it. Unfortunately this is not possible, and it never will be, since one of the
design prinicples of elog is to be independent of any other package, and with
the requested functionality you would need lots of helper functions (like
ghostview, pbmtools, etc.) which some of which are not present under Windows.

> - possibility to configure the scale of this view
> - possibility of build some thumbs in order to save BW and time

Using a HTML <img width=100 ...> does not help. The image is then shown in a
smaller scale, but still the full picture has to be transferred. For making
thumbnails, you again need external libraries (see point above).

So if you want extensive image processing, you might be better of with a picture
gallery like applications, but maybe the automatic attachment display shown
above helps a little bit.

> > One of the main and mandatory feature they cannot renunce is the possibility
> > of displaying every attached image just inline, without having to click over
> > the file name or to enter the entry view (in which the attachment can
> > already be displayed inline) ...  
> 
> Displaying images in the list view is possible by going to the "Find" page and
> checking "Display full entries" and "Show attachments". This can even be
> automatized by putting
> 
> Start page = ?mode=full&attach=1
> 
> into the configuration file. 

Perfect it works !! :-)

> 
> > - images (and hopefully ps, eps, pdf) be displayed inline just after the
> > text body of the message in the main "List" view
> 
> PS, EPS and PDF files cannot be displayed inline by the browser (at least not
> the browsers I know). I guess what you want is that users submit PDFs, and elog
> should convert the PDF automatically into JPG and display a reduced version of
> it. Unfortunately this is not possible, and it never will be, since one of the
> design prinicples of elog is to be independent of any other package, and with
> the requested functionality you would need lots of helper functions (like
> ghostview, pbmtools, etc.) which some of which are not present under Windows.
> 
> > - possibility to configure the scale of this view
> > - possibility of build some thumbs in order to save BW and time
> 
> Using a HTML <img width=100 ...> does not help. The image is then shown in a
> smaller scale, but still the full picture has to be transferred. For making
> thumbnails, you again need external libraries (see point above).

yes I know, but it could be a "placebo" :-P .. we are using the elog in a lan so it
could be a good temporary solution ...

can you point me to some documentation I can read to be able to do it? should I edit
the css file ?
> 
> So if you want extensive image processing, you might be better of with a picture
> gallery like applications, but maybe the automatic attachment display shown
> above helps a little bit.

yes, of course...

can be usefull to be able to "optionally" execute some external program (a sort of
pipe) in order to be (eventually) able to set a "filter program" for attachments.
The same way an MTA does with procmail I mean.

in this case one has to be able to access both to the original image and the
processed one...

> yes I know, but it could be a "placebo" :-P .. we are using the elog in a lan so it
> could be a good temporary solution ...
> 
> can you point me to some documentation I can read to be able to do it? should I edit
> the css file ?

No, I would have to add another option to the configuration file, it's not yet implemented. 

> can be usefull to be able to "optionally" execute some external program (a sort of
> pipe) in order to be (eventually) able to set a "filter program" for attachments.
> The same way an MTA does with procmail I mean.
> 
> in this case one has to be able to access both to the original image and the
> processed one...

Executing and external program is possible via the 

Execute new/edit/delete = ...

command. While you can pass attribute values to the program to be executed, it is not
possible right now to pass attachment names, although this could be easily added. What
would be harder is to reformat the whole entry. If you just downsample an image, that
would be ok. But if you want to keep the original, you would have to modify the logbook
entry to contain n*2 attachments afterwards, which would not be easy.

So I don't see a simple way of achieving what you want. Sorry.

> > yes I know, but it could be a "placebo" :-P .. we are using the elog in a lan so it
> > could be a good temporary solution ...
> > 
> > can you point me to some documentation I can read to be able to do it? should I edit
> > the css file ?
> 
> No, I would have to add another option to the configuration file, it's not yet implemented. 
> 

uhm ok .. can I expect to get a release with this feature in the near future ?

tnx in advance

> uhm ok .. can I expect to get a release with this feature in the near future ?

I checked how I would do that and did not find a good solution. If I put a

<img width=300 ...> 

for example, this scales down a big picture to only 300 pixels width. But if you submit a small
picture, like just an icon, it blows it up to 300 pixels as well, which does not look nice.
Unfortunatle I don't know of any option like "maxwidth=x" which only scales pictures down if they
are larger than x. Do you know?

> > uhm ok .. can I expect to get a release with this feature in the near future ?
> 
> I checked how I would do that and did not find a good solution. If I put a
> 
> <img width=300 ...> 
> 
> for example, this scales down a big picture to only 300 pixels width. But if you submit a small
> picture, like just an icon, it blows it up to 300 pixels as well, which does not look nice.
> Unfortunatle I don't know of any option like "maxwidth=x" which only scales pictures down if they
> are larger than x. Do you know?

the following should do the job:

<table><TR><TD width="200">
<img src="IMG_3133.jpg" width="100%">
</TD></TR></table>

or (better I think)

<div style="width: 200px">
<img src="IMG_3133.jpg" style="width: 100%" />
</div>

the configurable parameter should be with obviously :-)

> the following should do the job:
> 
> <div style="width: 200px">
> <img src="IMG_3133.jpg" style="width: 100%" />
> </div>
> 
> the configurable parameter should be with obviously :-)

Unfortunately not. Please find attached the screen dump from such a try, together with the HTML code.
As you can see, the little elog icon is stretched to the same width as the upper (large) picture.

> > the following should do the job: 
> >  
> > <div style="width: 200px"> 
> > <img src="IMG_3133.jpg" style="width: 100%" /> 
> > </div> 
> >  
> > the configurable parameter should be with obviously :-) 
>  
> Unfortunately not. Please find attached the screen dump from such a try, together with the HTML code. 
> As you can see, the little elog icon is stretched to the same width as the upper (large) picture. 
 
you are right ;-( I used a different code in my test and sent you and old test code, *but* also the last 
one does not works on every browser ... the following code would do the job, but it seems to work only 
in gecko-based browsers such as mozilla, firefox and safari ... 
 
<div style="width: 200px"> 
 <img src="IMG_3133.jpg" style="max-width: 200" /> 
</div> 
 
other browsers do not scale the vertical dimention :-( 

As I wrote you by mail, I implemented your idea in the following way. As you
say, it's only working on Gecko based systems. I did not implement additional
configuration parameters, but made it through the CSS file:

- adding a new CSS style "attachmentframe" around all attachments
- adding class "attachmentframe" to the 'default.css' like:

.attachmentframe {
  border:1px solid grey;
  border-top:1px solid lightgrey;
  border-left:1px solid lightgrey;
  background-color:white;
  padding:5px;
}

.attachmentframe img {
    max-width:100%;
}

The latter restricts the image size to 100%, which is the width of the 
browser window. I like it that, but of course you can write 200px or 
anything else. Please find the modified elogd.c and default.css under CVS.

> > uhm ok .. can I expect to get a release with this feature in the near future ?
> 
> I checked how I would do that and did not find a good solution. If I put a
> 
> <img width=300 ...> 
> 
> for example, this scales down a big picture to only 300 pixels width. But if you submit a small
> picture, like just an icon, it blows it up to 300 pixels as well, which does not look nice.
> Unfortunatle I don't know of any option like "maxwidth=x" which only scales pictures down if they
> are larger than x. Do you know?

the following patch should do the job:


#################################################################################
--- elogd_orig.c        2005-02-03 16:46:10.000000000 +0100
+++ elogd_imgscale.c    2005-02-08 18:58:14.000000000 +0100
@@ -13690,9 +13690,14 @@
                       ("<tr><td colspan=%d class=\"attachment\">%s %d: <a href=\"%s\">%s</a>\n",
                        colspan, loc("Attachment"), index + 1, ref, attachment[index] + 14);
                   if (show_attachments)
-                     rsprintf
-                         ("</td></tr><tr><td colspan=%d class=\"messagelist\"><img
src=\"%s\"></td></tr>",
-                          colspan, ref);
+                     if (!getcfg(lbs->name, "Attached image width", str, sizeof(str))) {
+                        rsprintf("</td></tr><tr><td colspan=%d class=\"messagelist\"><img
src=\"%s\"></td></tr>",
+                                 colspan, ref);
+                    } else {
+                        rsprintf("</td></tr><tr><td colspan=%d class=\"messagelist\">"
+                                 "<div style=\"width: %s\"><img src=\"%s\" style=\"width:
100%\"></div></td></tr>",
+                                 colspan, str, ref);
+                    }
                } else {
                   rsprintf
                       ("<tr><td colspan=%d class=\"attachment\">%s %d: <a href=\"%s\">%s</a>\n",
@@ -18090,7 +18095,10 @@
                   if (is_image(att)) {
                      rsprintf("<tr><td class=\"messageframe\">\n");
                      rsprintf("<a name=\"att%d\"></a>\n", index + 1);
-                     rsprintf("<img src=\"%s\"></td></tr>", ref);
+                     if (!getcfg(lbs->name, "Attached image width entry", str, sizeof(str)))
+                        rsprintf("<img src=\"%s\"></td></tr>", ref);
+                    else
+                        rsprintf("<div style=\"width: %s\"><img src=\"%s\" style=\"width:
100%\"></div></td></tr>", str, ref);
                      rsprintf("</td></tr>\n\n");
                   } else {
                      if (is_ascii(file_name)) {
##########################################################################################

two new elog.conf parameters are defined:
Attached image width          ; width of full view image attached
Attached image width entry    ; width of attached image in the entry list view

plz apply :-)

Are you sure that this does not stretch small images? Please see elog:931

> two new elog.conf parameters are defined:
> Attached image width          ; width of full view image attached
> Attached image width entry    ; width of attached image in the entry list view

I would rather go with a new class in the CSS file to contain this options, since I 
want to keep the number of options as small as possible.

current version uses strstr() to check if the file has the expected ascii
text extension ... this is buggy becouse this way a file named
".txt_hidden_file" or "foo.config.dat" are both seen as .txt files.

the following patch fixes the problem, plz apply to cvs:



#######################################################################
--- elogd_orig.c        2005-02-03 16:46:10.000000000 +0100
+++ elogd_extchk_fix.c  2005-02-08 17:32:21.000000000 +0100
@@ -1160,6 +1160,28 @@

 #define my_toupper(_c)    ( ((_c)>='a' && (_c)<='z') ? ((_c)-'a'+'A') : (_c) )

+static BOOL chkext(const char *str, const char *ext)
+{
+   int extl, strl;
+   char c1, c2;
+
+   if (ext == NULL || str == NULL)
+      return FALSE;
+
+   extl = strlen(ext);
+   strl = strlen(str);
+   if (extl >= strl)
+      return FALSE;
+   str = str+strl-extl;
+   while (*str) {
+      c1 = *str++;
+      c2 = *ext++;
+      if (my_toupper(c1) != my_toupper(c2))
+         return FALSE;
+   }
+   return TRUE;
+}
+
 BOOL strieq(const char *str1, const char *str2)
 {
    char c1, c2;
@@ -1168,6 +1190,8 @@
       return TRUE;
    if (str1 == NULL || str2 == NULL)
       return FALSE;
+   if (strlen(str1)!=strlen(str2))
+      return FALSE;

    while (*str1) {
       c1 = *str1++;
@@ -13698,8 +13722,8 @@
                       ("<tr><td colspan=%d class=\"attachment\">%s %d: <a
href=\"%s\">%s</a>\n",
                        colspan, loc("Attachment"), index + 1, ref,
attachment[index] + 14);

-                  if ((strstr(str, ".TXT") || strstr(str, ".ASC") ||
strstr(str, ".CFG")
-                       || strstr(str, ".CONF")
+                  if ((chkext(str, ".TXT") || chkext(str, ".ASC") ||
chkext(str, ".CFG")
+                       || chkext(str, ".CONF")
                        || strchr(str, '.') == NULL) && show_attachments) {
                      /* display attachment */
                      rsprintf("</td></tr><tr><td colspan=%d
class=\"messagelist\"><pre>", colspan);
@@ -14779,7 +14803,7 @@
    regex_t re_buf[MAX_N_ATTR + 1];
    regmatch_t pmatch[10];

-   /* redirect if enpty parameters */
+   /* redirect if empty parameters */
    if (strstr(_cmdline, "=&")) {
       while ((pt1 = strstr(_cmdline, "=&")) != NULL) {
          pt2 = pt1;
#######################################################################

> current version uses strstr() to check if the file has the expected ascii
> text extension ... this is buggy becouse this way a file named
> ".txt_hidden_file" or "foo.config.dat" are both seen as .txt files.

I added your routine chkext() to the code, but actually use it differently. I
display now ASCII files not by their extension, but the code checks for each file
to contain non-printable characters. If it contains all printable letters, and does
not have the extension PDF, PS or EPS, it's shown inline.

> > current version uses strstr() to check if the file has the expected ascii 
> > text extension ... this is buggy becouse this way a file named 
> > ".txt_hidden_file" or "foo.config.dat" are both seen as .txt files. 
>  
> I added your routine chkext() to the code, but actually use it differently. I 
> display now ASCII files not by their extension, but the code checks for each file 
> to contain non-printable characters. If it contains all printable letters, and does 
> not have the extension PDF, PS or EPS, it's shown inline. 
 
I totally agree with you choice :-) 

here is a piece of my current config:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Attributes = Author, Type, Category, Subject
Required Attributes = Author, Type, Subject

Options Type = Deposition{1}, Arc Studies{1}, Conditioning{1}, Vacuum{2},
Other{3}
Show Attributes = Author, Subject, Type

{1}ROptions Category = Nb, NbN, W, cavity system
{2}ROptions Category = pump, leak, mounting

{1}Show Attributes = Author, Subject, Type, Category
{2}Show Attributes = Author, Subject, Type, Category
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

this is an escamotage I use to have the option to be displyed.
I mean that something like the following:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Attributes = Author, Type, Category, Subject
Required Attributes = Author, Type, Subject
Options Type = Deposition{1}, Arc Studies{1}, Conditioning{1}, Vacuum{2},
Other{3}
Preset Type = Deposition

{1}ROptions Category = Nb, NbN, W, cavity system
{2}ROptions Category = pump, leak, mounting

{3}Show Attributes = Author, Subject, Type
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

rises a bug: the select input correctly shows "Deposition" as preselected
value, BUT the attributes shown are not those identified by the "{3}".
re-selecting by hand the "deposition" Type option everything goes right.

sorry for my bad english

 up :-)

> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> Attributes = Author, Type, Category, Subject
> Required Attributes = Author, Type, Subject
> Options Type = Deposition{1}, Arc Studies{1}, Conditioning{1}, Vacuum{2},
> Other{3}
> Preset Type = Deposition

The "Preset xxx" option actually never was ment to be used with conditional
attributes. I added that functionality in rev. 1.553. Please give it a try.

> > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 
> > Attributes = Author, Type, Category, Subject 
> > Required Attributes = Author, Type, Subject 
> > Options Type = Deposition{1}, Arc Studies{1}, Conditioning{1}, Vacuum{2}, 
> > Other{3} 
> > Preset Type = Deposition 
>  
> The "Preset xxx" option actually never was ment to be used with conditional 
> attributes. I added that functionality in rev. 1.553. Please give it a try. 
 
it works fine !!! thank you so much (btw, using Preset xxx{1} it doesn't 
works.. but it should be the correct beaviour)