MSDS in HTML

[Wouter Rijnbende]

Material Safety Data Sheet in HTML

Middels de module Profit-Safety-Datasheet is het mogelijk om MSDS-en te genereren. Per heden is hieraan toegevoegd de mogelijkheid dit in HTML te doen.

MSDS in HTML bestaat grofweg uit twee onderwerpen:

a. Het omzetten van de bestaande MSDS in HTML coding.
b. De mogelijkheid om zelf HTML teksten op te nemen incl. plaatjes e.d.

Aktiveren genereren MSDS in HTML

Om een MSDS in HTML op te kunnen bouwen, dient allereerst een hiertoe opgenomen Bedrijfsparameter met "Ja" te worden beantwoord:

Het genereren van een MSDS in HTML dient eigenlijk te worden gezien als een eerste opzet voor een volledig MSDS in HTML. Een klant gaat hiermee expirimenteren, waarbij vanzelf bekend wordt welke funktionaliteit aanvullend gewenst is, danwel anders opgezet moet worden. De verwachting is dat de komende tijd er nog diverse dingen veranderd zullen gaan worden alvorens de funktionaliteit definitief gebruikt kan worden.  Gesteld moet worden dat er vooralsnog geen formeel onderhoud bestaat op de betreffende funktionaliteit voor die klanten die niet zijn "aangewezen" ... ook niet op de gevolgen van het gebruik.

Het genereren van een MSDS in HTML dient expliciet geaktiveerd te worden met bovenstaande bedrijfsparameter.

Genereren MSDS

Via Hoofdmenu,1,3,1,5 (LORTOE) kan een MSDS worden gegenereerd. Hoe een MSDS precies in elkaar zit wordt niet uitgelegd; uitgangspunt is dat de werkwijze van MSDS-en bekend is. Indien een MSDS naar het scherm geprint (zonder HTML) dan ziet ze eruit als :

Het met Ja beantwoorden van de eerder genoemde bedrijfsparameter zorgt ervoor dat het MSDS wordt opgebouwd in HTML; het document ziet er dan als volgt uit:

Weliswaar HTML, maar nog steeds kaal.


Style Sheet (CSS)

Als we naar de HTML coding van deze pagina kijken, dan zien we dat ieder soort tekst van het MSDS een eigen Style-Class aanstuurt.

De volgende Style-Classes worden onderkend:

msds_header1
Eerste regel van de Header van het MSDS.
Bevat tekst welke in een TD-Tekst met de Identifikatie van het Technisch Document is vastgelegd.

msds_header2
Tweede regel van de Header van het MSDS.
Bevat tekst welke in een TD-Tekst met Identifikatie PRDAT kan worden vastgelegd, aangevuld met de datum waarop het MSDS gegenereerd werd.

msds_header3
Derde regel van de Header van het MSDS.
Bevat Artikelnummer + Artikelomschrijving.

msds_customer
N.A.W. gegevens van de (optioneel op te geven) Klant.

msds_footer
Afsluitende tekst van het MSDS.
Betreft de TD-Tekst met de Identifikatie van het Technisch Document + 'EINDE'.

msds_tdr_header
Omschrijving van een nieuwe TD-Rubriek

msds_tdsr_header
Omschrijving van een nieuwe TD-Sub-Rubriek

msds_tdr_text
Tekst horende bij een TD-Rubriek

msds_tdsr_text
Tekst horende bij een TD-Sub-Rubriek

msds_table
Definitie van een Tabel (kwa <div>)

msds_table table
Definitie van de tabel zelf.

msds_table th
Definitie van de tabelheaders.

msds_table tr
Definitie van de tabelregels.

Van ieder van de bovengenoemde Style Classes kan in een Style Sheet worden aangegeven hoe de betreffende class zich moet uiten. Welk lettertype, welke lettergrootte, welke regelafstand, welke kleur, welke achtergrond, wel-/geen borders... noem maar op... In principe de basis om alles aan te kunnen.

Stel dat we deze Style Sheet properties opnemen voor dit MSDS, dan ziet ze er al ineens kompleet anders uit (nb: let even niet op de kleuren, het betreft puur ter illustratie dat alles andere kleuren kan hebben).

Een Style Sheet is feitelijk gewoon een ASCII bestandje, met een extentie .CSS
De inhoud betreft de definitie van de hierboven genoemde Style Classes, en ziet er uit als :

Met een paar kleine aanpassingen in de Style Sheet, ziet hetzelfde MSDS er ineens kompleet anders uit, bijvoorbeeld een ander lettertype, of kleur:

Welke Style Sheet wordt gebruikt?

Printerdrivers zijn uitgebreid met de mogelijkheid te refereren aan een Style Sheet.

Hierbij mag worden verwezen naar een file op disk (netwerk of lokaal), maar er mag ook worden gerefereerd aan een URL (http://).

Wordt er verwezen naar een file op disk, dan zal de inhoud van die (.css) file worden gekopiëerd in het te genereren MSDS; als de inhoud van de .css file achteraf gewijzigd wordt, heeft dat geen invloed op hoe de MSDS getoond wordt, immers een kopie van de Style Sheet zoals die gold toen het MSDS gegenereerd werd, is opgenomen in het MSDS.

Wordt er gerefereerd aan een URL (http:// lokatie) dan zal de Style Sheet gelinkt worden aan die URL. Zodra de inhoud van de Style Sheet in de opgegeven URL wijzigt, wijzigen meteen alle MSDS-en kwa layout mee. Dit kan handig zijn, immers, met terugwerkende kracht kunt U de MSDS-en die in het verleden naar Uw klant verstuurd zijn er anders uit laten zien, omdat de Style Sheet informatie van Uw website wordt gelezen. Wil je niet dat een eerder verzonden document wijzigt kwa Style, dan moet je òf altijd de Style coding embedden in het document (ofwel verwijzen naar een file op disk) òf je zou moeten stellen dat een Style Sheet op Uw website nooit mag wijzigen, maar dat er hooguit een nieuwe bijkomt, en voortaan naar de nieuwe gerefereerd wordt.

Vervolgens is het slechts een kwestie van het Selekteren van de juiste Printerdriver, en het MSDS wordt volgens een kompleet andere Style opgebouwd.


TD-Teksten in HTML

De tweede aanpassing betreft de mogelijkheid tot het registreren van eigen teksten in HTML in plaats van met de Heart-editor. Uiteindelijk zal het de bedoeling zijn om overal de Heart-editor te vervangen door de DHTML editor, vooralsnog beginnen we met de TD-Teksten t.b.v. MSDS.

Nb: Merk op dat we technisch best zouden kunnen toestaan om ook aan een Verkooporder(-regel) HTML teksten te koppelen, maar zolang de overzichten waarop deze gegevens worden afgedrukt (Verkooporder, Opdrachtbevestiging, Faktuur) niet in HTML worde opgebouwd, zal e.e.a. per saldo alsnog geen zin hebben.

Via een nieuw Bedrijfsparametermenu optie zullen we stapsgewijs over kunnen stappen naar het registreren van Heart-editor teksten in DHTML, te beginnen met de Teksten van de Technische Documenten (TD-Teksten):

Indien bovengenoemde parameter aan staat, worden TD-Teksten vanaf dat moment via de DHTML editor bewerkt.

Indien TD-Teksten waarmee via de Heart-editor al teksten waren ingevoerd worden gewijzigd, dan zal deze tekst worden omgezet naar HTML.
Onderstaand wijzigen we bijv. de tekst van de header van het MSDS:

Let op:
Het getoonde lettertype Tahoma/3 is puur hetgeen wat in mijn browser als default ingesteld staat. HTML tekst kun je typen als 'ongeformatteerde tekst', in welk geval de tekst wordt getoond in het default lettertype van uw browser, maar je kunt ook expliciet een lettertype selekteren. Wil je dat de tekst in een specifiek lettertype op het MSDS wordt overgenomen, dan moet je expliciet een lettertype selekteren, wil je dat de default gebruikt conform de Style Sheet van het MSDS, dan moet je òf ongeformatteerde tekst gebruiken, òf tekst welke refereert aan dezelfde Style-Classnaam als waar in het MSDS aan gerefereerd wordt. Dit laatste kan echter alleen maar via het Tab 'Bron', en dat is niet handig.

V.w.b. het "pasten" van HTML tekst in het MSDS moet het mogelijk zijn om zelf eigen Style-Class tags aan te maken en aan te sturen. Belangrijk is dat ook dat de juiste Style-Class in het HTML document wordt aangegeven. Maar ja... wat als er nu niets is aangegeven ? Een van de wijzigingen die er aan zit te komen zal vermoedelijk zijn dat de <div> tekst uit het HTML document vertaald wordt naar <div class=msds_header1> tekst zodra het als header wordt afgedrukt. Die vertaling zit er nu niet in.

Als we enkel het de tekst centreren, en een plaatje invoegen:

Ziet het MSDS er als volgt uit:

De tekst is nu wit, en niet in een oranje kader, omdat deze in het MSDS gepaste tekst niet refereert aan de header class. Doen we dat voor nu even handmatig (via Tab Bron):

dan ziet het MSDS eruit als:

Wat ook opvalt, is dat de msds_header1 style een kader bevat. Die komt nu automatisch om alle drie de afzonderlijke regels te staan;
dat zijn precies de dingen die we bedoelen als we zeggen dat bepaalde dingen anders opgezet moeten worden.
Wat is handig? Wat is beter? Hoe kan het mooier?

[dirkjan]

Heel Mooi Wouter.

Klein vraag je. Kunnen de teksten ook inspringen, anders wordt de linkerkant zo recht.

Dirk-Jan

[Frank van Hofwegen]

komplimenten!

[Peter Stordiau]

Klein vraag je. Kunnen de teksten ook inspringen, anders wordt de linkerkant zo recht.

Tuurlijk. Zie handboek HTML. 

[dirkjan]

Heel leuk Peter

Maar ik vind dat je best wel een beetje trots kunt zijn op dit stukje werk.

Probeer nu dat zeepfabriekje eens de windows versie aan te smeren. Heb ze al een mailtje gestuurd van dit topic.

DJ

[Peter Stordiau]

De opmerking over dat handboek is toch wel serieus hoor. En serieus bedoeld ook. HTML is erg omvangrijk, en gaat uiteindelijk nog veel verder dan HTML-alléén ook. Zal ik je eens bang maken voordat je het bier in duikt ? http://www.w3.org/TR/ ... klein beetje naar beneden bladeren naar "Recommendations". Eigenlijk is dat allemaal HTML ... dan snap je ook wat een automatiseerdert doormaakt ...

Om het laatste gaat het niet, maar misschien wel om de complexiteit van zaken als je ze een beetje goed wilt doen. Bijvoorbeeld, de plaatjes die Wouter hier heeft gemaakt gaan niet om het mooie, maar om het krachtige van het concept. Dus, wat niet met zo veel woorden is gezegd, maar wat je met wat kennis van zaken wel al kunt zien is :

Als jij een website hebt, dan heb je -als je alles heel erg goed hebt gedaan- zo'n "style sheet" (CSS) om de layout zaken, lettertypen, kleuren enz. te bepalen. Als je dit heel-erg-goed-gestruktureerd in elkaar zet, kun je in één klap de layout en alles aanpassen, zonder dat zaken door elkaar komen te staan enz. Daarvoor zijn dus die "class" identifiers die domweg refereren naar "layout definities" die elders staan (in de CSS dus).
Als je het nu nog-veel-beter doet, pas je de style van je website aan, en loopt meteen je webshop mee die door derden is ontwikkeld. Vergelijk een website van Lampenier met een webshop van Heart-Profit. Dit "nog-veel-beter" doet zo ongeveer niemand (het is ook te moeilijk c.q. je hebt erg veel kennis nodig), maar die webshop van ons anticipeert er wel op.

Om aan te geven hoe moeilijk het is :
Wat we nu in elkaar hebben gedraaid, werkt met classes als msds_header1 en er is natuurlijk helemaal niemand die in de CSS van zijn website een dergelijke class heeft opgenomen. Die moet daar dus bij komen. Maar is dat wel juist ? nee, eigenlijk niet, want het betreft slechts één van de header definities die in de CSS van de website ook al aanwezig zijn, doch anders zijn genoemd. Redundant zoals dat heet, en dus betekent aanpassen - dubbel aanpassen. En dat was nu net de bedoeling niet.
Die link waar ik hierboven naar verwees, gaat eigenlijk aan alle kanten over de standaards die men moet hanteren, wil je goed met elkaar kunnen praten in deze. Dus, een bepaalde header zal een bepaalde standaard naamgeving kennen, en die is vast ergens binnen W3C gedefinieerd. Als wij die hadden gehanteerd voor de headers in de MSDS, en iedereen deed dat in zijn website ook, dan zou je inderdaad met één wijziging in de CSS alles aanpassen. Let wel, ook je kontakt verslagen, ook je Word dokumenten, ook je emails. Daar zie je allemaal niets van, maar dat komt eigenlijk omdat je het niet weet. Bekijk bijvoorbeeld de Bron-tab van een email maar eens, en zie dat dat hetzelfde eruit ziet als de bron-tab van het plaatje ergens in dit topic.

Omdat toch eigenlijk niemand die standaards allemaal kan behappen, heeft het (kip-ei) geen nut voor ons om ons er aan te houden. Dus, doe maar liever msds_header1 dan iets wat helemaal juist is maar vervolgens niemand begrijpt (het zou dan bijv. HDHD00x1 gaan heten, en sowieso door niemand wordt gebruikt.

Hoe slecht zo'n stellingname toch is, zie je aan de verschillende browsers waarbij de één iets wel kan, en de ander weer iets niet. Dit is ook het eerste wat je overkomt als je "mooie" dingen doet, dan blijkt het in bijv. IE7 niet te werken. Je mag dan ook geen mooie dingen doen, je moet via de standaards werken. En als je dàn mooie dingen blijkt te kunnen doen, merk je dat je vele jaren verder bent . Zie de link.

[BKienhuis]

Moet ik nog ergens rekening mee houden als ik de bewuste bedrijfsparameter 'Genereren MSDS in HTML' ga omzetten, of kan dat gewoon terwijl iedereen aan het werk is?

[Wouter Rijnbende]

Moet ik nog ergens rekening mee houden als ik de bewuste bedrijfsparameter 'Genereren MSDS in HTML' ga omzetten, of kan dat gewoon terwijl iedereen aan het werk is?<

Zou niet zo best zijn als iedereen aan het werk is in de Testbestanden 

Je vraagstelling impliceert dat je dit meteen van plan was te gebruiken in de Produktiebestanden; zou ik niet doen. Testen doen we in de Testbestanden...

De parameter kun je overigens gewoon omzetten als iedereen aan het werk is.

Nb: Omzetten mag van uit- naar aan, maar ook van aan- naar uit; Uitzetten wordt alleen een stuk lastiger als je eenmaal teksten in HTML hebt ingevoerd, immers, die worden enkel (juist) getoond als het MSDS ook in HTML wordt opgebouwd.

Wat dat betreft dus: eerst in test wat spelen, testen met css, welke kleurstellingen, lettertypes etc., en pas als alles akkoord is, de boel in produktie aktiveren.

[BKienhuis]

Oké, dan gaan we later deze week wel testen in de testbestanden...

[BKienhuis]

Hier dan de eerste testresultaten:

De link naar de volledige MSDS:
http://www.schaepman.nl/2006/pdflibrary/VWS/P2D000098.HTM

Ik vind het nog moeilijk om de tabellen op een goede manier te laten weergeven. Ik zou bijvoorbeeld graag de tabellen over de breedte van de pagina willen spreiden en de cellen lichtgrijs willen maken. Als ik de tabel lichtgrijs maak met background in de css, dan worden niet alleen de cellen grijs maar ook het gedeelte van de pagina aan de rechterkant.

In dit voorbeeld heb ik geen klantnaam ingevuld. Als ik dat wel doe, dan krijgt dit een gedeelte een class=msds_tdr_header mee. Dit betekent dat de opmaak hetzelfde wordt als de hoofdstuktitels, in dit geval met een groene achtergrond (niet zo mooi). Het zou misschien handiger zijn om deze onderdelen los van elkaar te kunnen aansturen.

Ik ben met de afbeelding bovenaan bezig geweest, waarbij ik diverse keren de afbeelding heb gewijzigd. De afbeelding heb ik telkens in c:\troep neergezet. Nu blijkt dat profit telkens een afbeelding in c:\troep maakt met dezelfde naam met nog wat tekens er voor (_2al0tbbc3-schaepman_logo6.gif) en dat dan voor alle afbeeldingen die zijn gebruikt, dat zijn dus inmiddels telkens 6 bestanden...

[Peter Stordiau]

Niet te geloven ... Mooi hoor !

In dit voorbeeld heb ik geen klantnaam ingevuld. Als ik dat wel doe, dan krijgt dit een gedeelte een class=msds_tdr_header mee. Dit betekent dat de opmaak hetzelfde wordt als de hoofdstuktitels, in dit geval met een groene achtergrond (niet zo mooi). Het zou misschien handiger zijn om deze onderdelen los van elkaar te kunnen aansturen.

Komt goed.

Ik ben met de afbeelding bovenaan bezig geweest, waarbij ik diverse keren de afbeelding heb gewijzigd. De afbeelding heb ik telkens in c:\troep neergezet. Nu blijkt dat profit telkens een afbeelding in c:\troep maakt met dezelfde naam met nog wat tekens er voor (_2al0tbbc3-schaepman_logo6.gif) en dat dan voor alle afbeeldingen die zijn gebruikt, dat zijn dus inmiddels telkens 6 bestanden...

Dit deel hoort bij Wouter (die even ziek is), en herken dit van het opnemen van plaatjes in Brieven / Kontakten. Zo heb ik zelf inderdaad honderden van die dingen in mijn \TROEP staan. Ik kan op dit moment niet zeggen wat het nut van het bewaren ervan is, en kan hooguit aangeven dat dit nodig is als tijdelijk "medium" voor plaatjes die op een bepaalde manier (!) in de tekst worden ingehangen. Is een beetje het verhaal wat Wouter eerder schreef (maar dan andersom) : als jouw css lokaal staat, dan zal ze ingekopieerd moéten worden.
Nu ik er zo over nadenk ... volgens mij is het verhaal andersom : wil je zelf zo'n plaatje kunnen zien, dan moet ze eerst ergens worden opgeslagen. Dit zou dan te maken moeten hebben met het proces van het werken in de DHTML Editor, en het dan zelf kunnen zien van het plaatje terwijl het niét is ingekopieerd a.g.v. de wijze waarop jij dat hebt ingehangen. Later, als de MSDS wordt gegenereerd vindt ook weer een "bijzonder" proces plaats, want dan moet zo'n plaatje weer worden ingekopieerd. Best ingewikkeld allemaal.

Als Wouter er weer is weet hij vast iets zinnigs te vertellen (ik niet dus), dan wel er iets aan te doen indien mogelijk.

Ik vind het nog moeilijk om de tabellen op een goede manier te laten weergeven.

Pas in elk geval op voor "trucjes" die dan in jouw browser wel werken, maar elders niet. Ofwel, je moet de gangbaren aan boord hebben om het te testen.
Wat je wil kan vast wel, maar met de opmerking dat als jij weet hoe het moet, je eventueel aan ons moet aangeven wat er zou kunnen veranderen om het "echt" of "echt makkelijk" te laten werken. Zoals al wel eerder gezegd, dit is een voorzet waarvan wij denken dat het voldoende kan zijn, maar zonder de werkelijke ervaring.

[Wouter Rijnbende]

Hey BKienhuis, ziet er prima uit ! En dat voor een eerste beginnetje  Ben benieuwd waar dat eindigt.

Als Wouter er weer is weet hij vast iets zinnigs te vertellen (ik niet dus), dan wel er iets aan te doen indien mogelijk.

Komt omdat de DHTML editor een HTML editor is, en geen Mime editor.

Dit vereist inderdaad wel wat meer uitleg om het te kunnen begrijpen...

De editor waarin je nu werkt is een DHTML editor. Alles wat je intypt wordt dus feitelijk een HTML bericht, en daarin heb je de mogelijkheid aan images te refereren, via een src=<drive:>\<dir>\<filename> konstruktie. Bij het MSDS in HTML heb ik hetzelfde uitgangspunt genomen als bij de Kontakten-/Mailberichten: eventuele referenties (images) behoren als Embedded Content in het bericht te worden opgenomen, immers, wie zegt dat het plaatje er nog staat tegen de tijd dat iemand anders het verslag opvraagt?  Of, hoe anders zorg je ervoor dat jij kunt refereren aan een plaatje op drive c: en zodat iedereen dit toch kan zien?

Daarmee komt vervolgens een klein probleem om het hoekje... Embedded Content tref je niet aan in een normaal HTML bericht; wel in een Mime Bericht (*.EML documenten, krijg je als je een email bericht opslaat (Opslaan Als)). Zodra iemand een DHTML verslag maakt en daar een plaatje in opneemt, wordt dit plaatje bij het saven hieruit gelezen, vertaald naar Embedded Content, en opgenomen in het bericht. Als iemand het verslag weer wijzigt, tsja... dat kan 10 seconden later zijn, dan kan ook een jaar later zijn, het kan op een andere pc zijn etc. Ofwel, uitgangspunt moet zijn dat die image er dan niet meer is. In het Mimebericht zal de image zijn vertaald naar Content-Id, en in je HTML bericht (View Source) zie je dat je "src=" regel verwijst naar "cid:<content-Id-referentie>". De DHTML editor is echter een HTML editor en geen Mime editor; ze herkent deze "cid:" referentie niet. Derhalve wordt bij het opvragen van het bericht de Embedded Content weer vertaald naar een echte image (in de \troep directory) en wordt de cid: referentie weer vertaald naar die image in \troep. Op die manier zie je toch het plaatje.

Vergelijk e.e.a. maar met de wijze waarop dit normaliter ook gebeurt als je bijv. een attachment uit een mailbericht opent; Windows slaat deze op in ..\Temporary Internet Files\<temp dir.>\<filename> en dit blijft daar veelal net zolang staan tot het er een limiet bereikt wordt. Zoiets hebben we in Profit (nog) niet, maar zou in principe ook niet nodig hoeven te zijn. Alles wat in de \TROEP directory staat is "troep", en feitelijk zouden we bij het opstarten van Profit deze hele directory leeg mogen maken. Omdat wij hier meerdere Applikaties hebben draaien (die met dezelfde \TROEP directory werken) doen we dat toch maar even niet, en uiteindelijk blijven al deze bestanden staan. Neemt niet weg dat je zelf zo af en toe al die files gewoon kunt verwijderen...

Bij het MSDS in HTML wordt het nog een tikkie lastiger, immers, daar wordt één HTML document gegenereerd uit een variabel aantal andere (mogelijke HTML) teksten. In theorie kun je meerdere TD-Teksten gedefinieerd hebben, met beide daarin een image genaamd 'scherm1.jpg', doch waarin in beide gevallen scherm1.jpg een totaal andere inhoud bevat. Toch moeten beide images met hun juiste inhoud tot uiting worden gebracht in het MSDS document. Dit is de reden dat de Embedded Content bij het MSDS in HTML wordt voorzien van een unieke naam, bijv. "_2aj0kigbm". Ik heb er echter voor gekozen om niet enkel deze unieke naam te gebruiken, maar dit als voorvoegsel op de oorspronkelijke naam te gebruiken, opdat je, bladerend door View Source, of door de \TROEP directory, toch nog enig inzicht hebt in welk plaatje waar staat. Dit dus v.w.b. dat voorvoegsel op de imagenaam.

Er is ook nog een kombinatie tussen HTM en EML (Mime) en dat is een bestand met een extentie MHT (Web-Archief). Een Web-archief kun je maken door een internet pagina op te slaan als Web-archief. Zo'n Web-archief is eigenlijk hetzelfde als een Mime bericht, hooguit ontbreken de gegevens die te maken hebben met het emailen op zich. Middels een MHT document ben je in staat om een HTM pagina te maken en daarin de images te embedden als content. Het MSDS in Profit wordt ook op deze manier opgebouwd, immers, zouden we dat niet down, dan heb je (slechts) een HTML document welke verwijst naar images als src="c:\troep\_2aj0kigbm-heartprofit.jpg". Verstuur de PRFILE.HTM naar iemand anders, en niemand kan dit lezen, omdat het plaatje niet gevonden kan worden. Ook al had je gerefereerd aan een plaatje op een netwerkdrive, dan zouden anderen in jouw netwerk dit  nog wel kunnen lezen, maar buitenstaanders niet. Hier dus de noodzaak e.e.a. te embedden als content.

[BKienhuis]

Tja, op zich vond ik het inderdaad logisch dat de afbeelding als 'temporary file' mee komt, alleen dat dan ook alle vorige versies mee komen...ik kan nergens achterhalen waar deze vandaan komen.

Ik ben met de tabellen al wel weer ietsje verder, alleen moet ik daarvoor handmatig wijzigingen doorvoeren, misschien dat jij daar wel iets voor weet. Ik heb in de stylesheet dit toegevoegd:
#tabel {
   width:      85%;
   margin-left:   70px;
}
Daarna heb ik in de htm-file een id toegevoegd bij de tabellen:
<div class=msds_table><table id="tabel" border=1><tr><th align=left>Naam</th><th align=right>Conc.bereik</th><th align=left>CAS-no.</th><th align=left>EINECS-no.</th></tr>
De tabel is nu geplaatst in lijn met de tekst (inspringen vanaf linker kantlijn) en de breedte is in te stellen (in dit geval 85%). Het komt er dan zo uit te zien:

De vraag is dan wel: hoe krijg ik een id aan de tabellen waarmee ik vervolgens de layout heel makkelijk kan veranderen?

[Wouter Rijnbende]

Tja, op zich vond ik het inderdaad logisch dat de afbeelding als 'temporary file' mee komt, alleen dat dan ook alle vorige versies mee komen...ik kan nergens achterhalen waar deze vandaan komen.

Iedereen keer dat je het MSDS in HTML genereert kriigen deze images een nieuwe naam; de tekst verwijst immers naar 'scherm1.jpg' en die naam wordt bij de opbouw van het MSDS uniek gemaakt. 2 MSDS sen genereren en er is 2x een unieke filename toegekend. Nogmaal, eigenlijk moet het mechanisme van zichzelf weten welke filenames er tijdelijk gebruikt zijn, en moeten die verwijderd worden.

Wellicht nog beter: net als dat er in Windows bij 'Temporary Internet Files' een unieke directory verschijnt, zouden we per Profit sessie een Subdirectory kunnen maken in de \TROEP directory en dáár al temporary files in kunnen zetten. Bij het afsluiten van de Profit sessie zou dan de hele directory verwijderd moeten worden. Zou je echter maar 1 sessie tegelijkertijd (kunnen) hebben, dan is dit hetzelfde als de huidige Troep directory.

Als je de \TROEP directory nu maar als "troep" ziet, dan interesseert het je niet eens wat er in die directory staat; als wij die directory 'hidden' en ergens in 'document & settings\local settings' hadden opgenomen, had je er nooit naar gekeken.

Misschien zit het verschil hem wel in het feit dat er in die directory ook output van printoverzichten (PRFILE.PRN /.XLS/.HTM) wordt opgeslagen, en dat "minder troep" is dan de temporary files zoals in deze teksten.

[Wouter Rijnbende]

Ik ben met de tabellen al wel weer ietsje verder, alleen moet ik daarvoor handmatig wijzigingen doorvoeren, misschien dat jij daar wel iets voor weet. Ik heb in de stylesheet dit toegevoegd:

Ik ga even voor je kijken...