Größe von eingebetteten Bildern ermitteln

[rar]

Hallo ihr Zwischenweihnachtenundneujahrforumaktiven,

kennt ihr zufällig eine Möglichkeit mir der ich die Größe von eingebetteten Bildern in einem RTF ermitteln kann? Ähnlich wie notesEmbeddedObject.FileSize

lG
-daniel

[pram]

Dies funktioniert über DXL und ist nicht unbedingt einfach. (Ein anderer Weg wäre mir nicht bekannt, zumindest in LS. Ggf. könnte man aber den HTTP-Task "missbrauchen")

Wie man Bilder exportiert kannst du dir hier ansehen.
http://www.openntf.org/Projects/codebin/codebin.nsf/0/A089BEEADCA0A1A9862573000052B474
Wenn du zus. noch die Abmessungen willst, brauchst du die Spezifikation von GIF/JPG, diese findest du z.B. auf www.wotsit.org

Gruß
Roland

[eknori]

DXL ist eine Möglichkeit; C-API eine andere.

Habe mal ein kleines Programm zusmmengebaut, das die CD REcords eines Richtext Feldes ausliest und auflistet. Die gesuchten Daten stecken entweder in der struct CD_IMAGEHEADER oder man addiert einfach die Recordlängen von CD_IMAGESEGMENT.

Das "Dos" Fenster zeigt die Ausgabe meines Programms, zur Kontrolle habe ich die Daten auch mal mit NotesPeek dargestellt.

Bevor jetzt die Frage aufkommt; nein, mit LS2CAPI kann man da nix machen, da Lotusscript keine Callbacks unterstützt.

[eknori]

mit ein paar Zeilen Code mehr bekomme ich jetzt die Grösse aus dem CD_IMAGEHEADER geliefert

[eknori]

und hier der ( abgespeckte ) Quelltext:

Code

#include <stdio.h>
#include <string.h>
#include <global.h>
#include <nsfdb.h>
#include <nsfnote.h>
#include <oleods.h>
 
/* Prototypes */
STATUS LNPUBLIC ProcessOneCDRecord( 
								   char   *RecordPtr, 
								   WORD    RecordType, 
								   DWORD   RecordLength, 
								   void   *p_ptr_void );
void CleanUp(
			 DBHANDLE db_handle, 
			 NOTEHANDLE note_handle);
 
void ProcessImageHeader( 
						char *RecordPtr, 
						DWORD RecordLength,  
						WORD RecordType );
 
int main(int argc, char *argv[])
{	
	char db_filename[]="rt.nsf";
	DBHANDLE db_handle; 
	NOTEHANDLE note_handle;
	STATUS error = NOERROR; 
	char itemname[] ="Body";
	DWORD NoteID = 2294;
	BLOCKID item_blockid;
	BLOCKID value_blockid;
	WORD value_datatype;
	DWORD value_len;
 
	if (error = NotesInitExtended (argc, argv))
	{ 	printf("\n Unable to initialize Notes.\n");
	return (1);	}
 
	/*Open Database*/
	if (error = NSFDbOpen (db_filename, &db_handle))
	{ 	printf("\n Unable to open database.\n");
	NotesTerm();
	return (1);	}
 
	/*Open Note*/
	if (error = NSFNoteOpen (db_handle, NoteID, 0, &note_handle))
	{ 	printf("\n Unable to open note.\n");
	NotesTerm();
	return (1);	}
 
	if (error = NSFItemInfo (
		note_handle, 
		itemname, 
		strlen(itemname), 
		&item_blockid, 
		&value_datatype,
		&value_blockid,
		&value_len))
	{ 	
		printf("\n Unable to get note-info.\n");
		CleanUp (db_handle, note_handle);
		return (1);	
	}
 
	if (error = EnumCompositeBuffer( 
		value_blockid, 
		value_len, 
		ProcessOneCDRecord,
		NULL ) )
	{
		CleanUp(db_handle, note_handle);
		return(0);
	}
 
	if (error = NSFDbClose (db_handle))
		return (1);
 
	NotesTerm();
	return (0);
}
 
/*************************************************************************
FUNCTION:   CleanUp
**************************************************************************/
void CleanUp(DBHANDLE db_handle, NOTEHANDLE note_handle) 
{
	NSFDbClose (db_handle);
	NSFNoteClose (note_handle);
	NotesTerm();
}
 
/************************************************************************
FUNCTION:   ProcessOneCDRecord
*************************************************************************/
STATUS LNPUBLIC ProcessOneCDRecord( 
								   char   *RecordPtr, 
								   WORD RecordType, 
								   DWORD RecordLength, 
								   void *p_ptr_void )
{
	switch (RecordType)
	{
	case SIG_CD_IMAGEHEADER:
 
		ProcessImageHeader( RecordPtr, RecordLength, RecordType );
		break;
	}
	return(NOERROR);
}
 
/*************************************************************************
FUNCTION:   ProcessImageHeader
**************************************************************************/
 
void ProcessImageHeader( char *RecordPtr, DWORD RecordLength,  WORD RecordType )
{
	char far *			p = RecordPtr;
	char ImgType[4];
	CDIMAGEHEADER		cdImgageHeader;
 
	ODSReadMemory( &p, _CDIMAGEHEADER, &cdImgageHeader, 1 );
	printf("\n");
	printf("Embedded Image Groesse: %d Bytes\n", cdImgageHeader.ImageDataSize); 
	printf("Embedded Image Breite: %d Pixel\n", cdImgageHeader.Width); 
	printf("Embedded Image Hoehe: %d Pixel\n", cdImgageHeader.Height); 
 
	switch (cdImgageHeader.ImageType)
 
	{
	case CDIMAGETYPE_GIF:
		strcpy (ImgType,"GIF");
		break;
 
	case CDIMAGETYPE_JPEG:
		strcpy (ImgType,"JPG");
		break;
 
	case CDIMAGETYPE_BMP:
		strcpy (ImgType,"BMP");
		break;
	}
 
	printf("Embedded Image Type: %s \n", ImgType);
	return;
}

[eknori]

nein, mit LS2CAPI kann man da nix machen, da Lotusscript keine Callbacks unterstützt.

Kleine Korrektur: Mit ein paar Tricks geht das doch in gewissen Grenzen. Wie das funktioniert, verrate ich auf dem EntwicklerCamp

[eknori]

Nochmal zurück zur Ausgangsfrage:

kennt ihr zufällig eine Möglichkeit mir der ich die Größe von eingebetteten Bildern in einem RTF ermitteln kann?

Ja, es gibt (mindestens) eine Möglichkeit.

1 - Lotusscript:
keine Standardfunktion; man kommt aber über das parsen der CD Records in einem Richtext Feld an die Informationen heran. ( Zeige ich auf dem EntwicklerCamp 2010 ).
Allerdings ist der Aufwand bei unbekanntem Inhalt des RT Feldes enorm. Man einige hundert Definitionen in einem Select behandeln. Das ist zwar nicht zeitintensiv aus Sicht der Codeverarbeitung, aber enorm arbeitsintensiv, was das Zusammensuchen der Informationen und das Einbinden in eine ScriptLib angeht.

2 -C-API:
Die wohl "einfachste" Art, diese Funktion zu realisieren. Code habe ich ja bereits oben gepostet. Den kann man als DLL aufbauen. Da muss man zu dem gezeigten Code noch ein paar Zeilen dazustricken. Das ist kein Hexenwerk.
Funktionsprototyp muss dann in der Declaration section angegeben werden.

3 -LSX:
Hier steht dann die Funktion aus (2) auch im Designer zur Verfügung. Macht Sinn, wenn man eh schon eine LSX hat, in die man die Funktion einbaut. "From Scratch" lohnt sich das Erstellen einer LSX für nur eine Funktion nicht.
Da kann man auf die DLL aus (2) ausweichen; auch eine LSX ist ja eine DLL und muss extra verteilt werden.

[flaite]

Mit Java sollte es auch gehen.
Denk aber, das dieser DXL Code von Andre Guirard (spell?) die einfachste Lösung darstellt. 
http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/rt-validation-image

[koehlerbv]

Der Code von der IBM-Seite funktioniert aber mit R7 noch nicht, Axel.

Bernhard

[flaite]

Mit Java hat man das Problem auf eingettete Bilder ranzukommen. Attachments sind kein Problem.
Wir haben das hier (für Attachments) auf Basis von dem gelöst:
http://kickjava.com/src/imageinfo/ImageInfo.java.htm
Damit kann man auch Thumbnails erzeugen.
Vor vielen, vielen Jahren.
Heute gibts vermutlich bessere Lösungen.

Eingebettete Bilder sind allerdings wirklich ein Problem (mit Java). Da braucht man C-code für, um an den InputStream ranzukommen.

Keine Zeit das jetzt auszuprobieren. Was funktioniert da mit R7 nicht?  
Der Code von Andre Guriard (spell?) kann jedenfalls als gute Vorlage dienen.

Imho könnte das so schon mit R7 funktionieren:

Code

Sub Querysave(Source As Notesuidocument, Continue As Variant) 
        Dim doc As NotesDocument 
        On Error Goto oops 
        Source.Refresh True ' update rich text data into back end. 
        Set doc = Source.Document 
        Dim session As New NotesSession 
        Dim stream As NotesStream 
        Dim dxle As NotesDXLExporter 
        Dim domp As NotesDOMParser 
        Dim domd As NotesDOMDocumentNode 
        Dim nl As NotesDOMNodeList 
        Set stream = session.CreateStream 
        
        Set dxle = session.CreateDXLExporter(doc, stream) 
        dxle.RestrictToItemNames = "Body" 
        ' at this point you might want to set additional properties for efficiency, e.g. to omit attachments 
        ' please note that if you want to disallow certain types of content, you can use a Rich Text Lite field, 
        ' so this is not the preferrred way to block users from adding an image. 
        dxle.Process 
        Set domp = session.CreateDOMParser(stream) 
        domp.Parse 
        Set domd = domp.Document 
        Set nl = domd.GetElementsByTagName("picture") 
        If nl.NumberOfEntries <> 1 Then 
                Msgbox "You must have exactly one image in the Body field." 
                Continue = False 
                Exit Sub 
        End If 
        Dim picture As NotesDOMElementNode 
        Set picture = nl.GetItem(1) 
        Dim picX As Long, picY As Long 
        picX = Clng("0"+Strleft(picture.GetAttribute("width"), "px")) 
        picY = Clng("0"+Strleft(picture.GetAttribute("height"), "px")) 
        If picX > 400 Or picY > 400 Then 
                Msgbox "The image may not exceed 400x400 pixels." 
                Continue = False 
                Exit Sub 
        End If 
        If stream.Bytes > 160000 Then 
                Msgbox "The image is too large. Please IMPORT the image from a GIF or JPEG file; do not paste graphics or import a BMP file. Thanks." 
                Continue = False 
                Exit Sub 
        End If 
        ' else: success! 
        Exit Sub 
oops: 
        ' if a validation failure don't bother to display the error because user already saw one. 
        If Err <> 4412 Then Msgbox "Error " & Err & " in Querysave line " & Erl & ": " & Error 
        Continue = False 
        Exit Sub 
End Sub
 

In jeden Fall muß man das DXL nicht auf Platte schreiben. Ein parsen der XML Repräsentation reicht aus.
Der code ist für mich die Notes Programmier Entdeckung des Jahres.

[koehlerbv]

Andre Guriard (spell?)

Dein erster Versuch war besser 

Und unter R7 gab es NotesDXLExporter.RestrictToItemNames noch nicht.

Bernhard

[flaite]

Ich denke, dass man dies nicht benötigt und lediglich zur Optimierung der Performance dient.

Gruß Axel

[koehlerbv]

Ja, richtig, Axel. Allerdings darf man dann auch nicht mehr als ein RTI im Dokument haben, sonst verfehlt der ganze Code seinen Sinn.

Bernhard

[flaite]

Das liesse sich bewerkstelligen, den Namen des Items zu ermitteln.
In der DomNodeList nl sind DomNode-Elemente. Von diesen läßt sich auf Parent Nodes navigieren (Methode Parent). Dom Nodes sind datenstrukturmässig doppelt verkettete Listen.

Kann vielleicht mal jemand ausprobieren. Halte das für einen guten Ansatz. In echt.


 

[pram]

Du könntest noch ein XSL Stylesheet mit dem XSLT-Transformer davor schalten, welcher dir genau das Item extrahiert. Siehe Beispiel.
Ggf. kannst du den X-Path sogar bis auf den Picture Tag runter brechen.

Code

<?xml version="1.0" encoding="UTF-16" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:doc="http://www.lotus.com/dxl">
<xsl:template match="/doc:document">
	<xsl:apply-templates select="doc:item[@name='body']" />
</xsl:template>
 
<xsl:template match="doc:item">
	<xsl:copy-of select="./child::*" />
</xsl:template>
</xsl:stylesheet>

Gruß
Roland

[flaite]

Hab heute Besserwisser-Tag. 
Pram, ist eine Alternative.
Dann müsste man aber wieder das Stylesheet irgendwo speichern, das holen, prozessieren, nicht vergessen die Streams zu schliessen.
Ich denke, in diesem Fall wäre es einfacher durch das DOM-Document zu navigieren.
Möglicherweise rekursiv.

[pram]

Hi Pitiyankee, ich auch. 
Ich konnte mich bis jetzt noch nicht wirklich mit dem DOM-Parser anfreunden. Ich vermisse da Methoden wie getElementsByTagName etc...
das XSL musst du nicht speichern, das kannst du mit stream.writeText auch temporär in einen Stream schreiben.

ansonsten ist das Verfahren über DXL wohl besser, was Kompatibilität anbelangt.
Das Verfahren funktioniert jedenfalls auch unter Notes 6.5 und Linux (wenn hier auch wie oben schon erwähnt, die ein oder andere Methode nicht verfügbar ist)

Gruß
Roland