Kan ik een 'rauwe' ASCII pagina, met <PRE>, alsnog onafhankelijk van scherm-breedte laten weergeven?

[Willem-Jan Markerink]

Heb ooit een paar 'kladblok-achtige' webpagina's met rauwe ASCII-content
middels <PRE> tags opgetuigd....tijdje geleden gemerkt dat die op tablets
toch wel erg vernaggeld worden, cq blijkbaar toch niet tot een vaste
regellengte worden gedwongen, en alsnog gaan inspringen op smalle schermen.

Kan ik daar nog iets *simpels* aan tags aan toevoegen, cq zonder dat het bij
de volgende browser-generatie danwel protocol-afspraken weer als een
kaartenhuis in elkaar dondert?
(want dat was en is voor mij nog steeds een goede reden om het lekker bij
ASCII te laten, en Notepad als editor....:))
(ipv ziek ruimtevretende HTML-bagger die binnen de kortste keren toch al niet
meer compatible is met nieuwere editors of browsers....8-))


Alzodus, wie mijn KISS-prinsiep nog wat weet op te rekken met een goede tag-
tip, graag....;))

--
Bye,

Willem-Jan Markerink

The desire to understand
is sometimes far less intelligent than
the inability to understand

<w.j.ma...@a1.nl>
[note: 'a-one' & 'en-el'!]

[Bert (AWRvB)]

Op 13-12-2012 03:36, Willem-Jan Markerink schreef:> Heb ooit een paar

'kladblok-achtige' webpagina's met rauwe ASCII-content
> middels <PRE> tags opgetuigd....tijdje geleden gemerkt dat die op tablets
> toch wel erg vernaggeld worden, cq blijkbaar toch niet tot een vaste
> regellengte worden gedwongen, en alsnog gaan inspringen op smalle
schermen.
>
> Kan ik daar nog iets *simpels* aan tags aan toevoegen, cq zonder dat
het bij
> de volgende browser-generatie danwel protocol-afspraken weer als een
> kaartenhuis in elkaar dondert?

<span> </span>

<br>

> (want dat was en is voor mij nog steeds een goede reden om het lekker bij
> ASCII te laten, en Notepad als editor....:))
> (ipv ziek ruimtevretende HTML-bagger die binnen de kortste keren toch
al niet
> meer compatible is met nieuwere editors of browsers....8-))

Ik vind het voor indexen leuk maar verder gebruik ik de kladblok!

>
>
> Alzodus, wie mijn KISS-prinsiep nog wat weet op te rekken met een
goede tag-
> tip, graag....;))

alinea <p> </p>

<nobr> </nobr>

<br>
Let op </br> bestaat niet

tekstblok
<div> </div>
hierna volgt een nieuwe regel met daarop volgend een nieuwe alinea

tekstdeel
<span> </span>







--
Bert ( A W RvB )
(Adres op website)
be...@awrvb.nl
http://www.awrvb.nl
Twitter: awrvbnl


***
US spaceships maximum velocity:
One light-year a minute.
http://projectcamelot.org/lang/en/clifford_stone_interview_transcript_en.html
***
AWN http://www.awn-archeologie.nl
GEA http://www.gea-geologie.nl
NVR http://www.ruimtevaart-nvr.nl
Sterrenkunde http://www.dekoepel.nl
UFOwijzer http://ufowijzer.nl

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:

> Heb ooit een paar 'kladblok-achtige' webpagina's met rauwe ASCII-content
> middels <PRE> tags opgetuigd....tijdje geleden gemerkt dat die op tablets
> toch wel erg vernaggeld worden, cq blijkbaar toch niet tot een vaste
> regellengte worden gedwongen, en alsnog gaan inspringen op smalle
> schermen.

Mijn iPhone laat PRE zien zoals op de desktop: te lange regels vallen
over de rand van het scherm heen. Dat zal voor de meeste Webkit-
gebaseerde browsers wel het geval zijn.

Maar misschien begrijp ik niet wat je bedoelt met 'inspringen', ik versta
daar 'text indent' onder en ik kan me niet voorstellen dat browsers *dat*
gaan doen.

--
robert

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in
news:slrnkcj05e...@my.local.lan:

Mogelijk ligt het ook aan brakke tablet-browsers, bedacht ik me later, maar
de opsomming die Bert gaf ziet er op het eerste gezicht wel aardig uit.
(als ik daar 10-15 jaar geleden naar gezocht had dan was ik die wellicht toen
wel tegengekomen, omdat er weinig anders was, momenteel lijkt dit een
onvindbare niche geworden)


Hier een voorbeeld van een persoonlijk kladblokje, dat ooit onschuldig als
klein tabelletje begon, maar qua regellengte een beetje uit de klauwen is
gelopen....:))

http://www.markerink.org/WJM/HTML/tow_NATO-hitches.txt



En deze lijkt op het oog wel okay qua breedte, maar mij heugt dat ik juist
die op een tablet vernaggeld zag:

http://www.markerink.org/WJM/HTML/tow_NATO-plug-layout_GEN-UK-BRD-SE.txt



PS: ondergetekende beoogt met voornoemde web-creaties weder beklag noch
hoon....;))
(cq geen van beide zal mij ook maar 1 sikkepit doen bewegen het anders aan te
pakken, laat staan ingewikkelder....;))
(en WYSIWYG, maar tablets lijken daar dan toch weer schijt aan te hebben)


(wel beklag heb ik met diegenen die eea willen printen, maar wat dat betreft
krijg ik in toenemende mate andermans meest simpele pagina's al niet meer
fatsoenlijk op papier, ongeacht browser of printerinstellingen, dus al te
schuldig hoef ik me daar ook niet meer over te voelen....;))

(want linksom of rechtsom, zulke brede tabellen passen sowieso alleen nog,
leesbaar, op A3)

[Willem-Jan Markerink]

"Bert (AWRvB)" <reije...@newsxs.nl> wrote in news:73471$50c945cb$53523b3b
$39...@abuse.newsxs.nl:

Klinkt/oogt aannemelijk, ga ik eens mee stoeien, thanx!

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:

> Hier een voorbeeld van een persoonlijk kladblokje, dat ooit onschuldig als
> klein tabelletje begon, maar qua regellengte een beetje uit de klauwen is
> gelopen....:))
>
> http://www.markerink.org/WJM/HTML/tow_NATO-hitches.txt

Oh maar wacht, je schreef <PRE> dus dacht ik dat je een simpele HTML pagina
had met in een <PRE> die rauwe tekst, maar de url die je noemt verwijst
direct naar een tekstbestand. Daar mag een browser mee doen wat ie wil, en
ook mijn desktop-browser (Chrome) breekt regels af bij het kleiner maken
van het scherm.

Zonder dat je er een echte HTML-pagina van maakt heb je vrij weinig
zeggenschap over hoe een browser zo'n bestand moet tonen.

--
robert

[EeBie]

On Thu, 13 Dec 2012 02:36:46 +0000, Willem-Jan Markerink wrote:

> Heb ooit een paar 'kladblok-achtige' webpagina's met rauwe ASCII-content
> middels <PRE> tags opgetuigd....tijdje geleden gemerkt dat die op
> tablets toch wel erg vernaggeld worden, cq blijkbaar toch niet tot een
> vaste regellengte worden gedwongen, en alsnog gaan inspringen op smalle
> schermen.
>
> Kan ik daar nog iets *simpels* aan tags aan toevoegen, cq zonder dat het
> bij de volgende browser-generatie danwel protocol-afspraken weer als een
> kaartenhuis in elkaar dondert?
> (want dat was en is voor mij nog steeds een goede reden om het lekker
> bij ASCII te laten, en Notepad als editor....:))
> (ipv ziek ruimtevretende HTML-bagger die binnen de kortste keren toch al
> niet meer compatible is met nieuwere editors of browsers....8-))
>
>
> Alzodus, wie mijn KISS-prinsiep nog wat weet op te rekken met een goede
> tag- tip, graag....;))

Misschien met de CSS white-space property:

http://www.w3schools.com/cssref/pr_text_white-space.asp

--
EeBie

[Bert (AWRvB)]

Op 14-12-2012 07:29, Willem-Jan Markerink schreef:

Ik heb deze boekjes:

Basishandleiding
HTML voor websites
Jan Kampherbeek
Bijleveld Press

Basishandleiding
HTML 4 & internet
Jan Kampherbeek & Gerard Staal
Bijleveld Press

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkcllp7...@my.local.lan:

Ha'k al wel gedacht, waarom simpel als het ook moeilijk kan....;((

Crux zit hem in de .txt blijkbaar (na wat gefroebel & testen).

En die veranderen in .html heb ik een nog grotere hekel aan, want als .txt is
die als publieke URL al jaren in omloop, cq zonder redirect stuur ik
bezoekers het bos in.

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:

> En die veranderen in .html heb ik een nog grotere hekel aan, want als
> .txt is die als publieke URL al jaren in omloop, cq zonder redirect stuur
> ik bezoekers het bos in.

Als tussenoplossing zou je de serverconfig kunnen aanpassen (indien
mogelijk) zodat de .txt files worden uitgestuurd met text/html als content-
type, dan kan de browser ze als HTML beschouwen. Maar dan nog zul je ze
moeten aanpassen (alhoewel het waarschijnlijk al genoeg is om <PRE> en
</PRE> om de tekst heen te zetten).

--
robert

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkco8e1...@my.local.lan:

Zijn er maar een paar, van die (inmiddels honderden....:)) .txt files, die zo
breed zijn uitgewoekert, dus als ik dat voor die paar files
invidueel/handmatig kan doen is het ook goed (en dat <PRE>/</PRE>
idem)....en/want ergens komt mij dat 'text/html' namelijk bekend voor, alsof
het ook in de pagina zou kunnen staan?

Weet niet hoe diep ik die server-config in moet/kan duiken; het is mijn eigen
domain, bij hostmonster.com (shared hosting), dat zou genoeg moeten zijn,
toch?

Thanx!....:))

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:

> US3N37+{n.i.w.o}@gmail.com (robert) wrote in
> news:slrnkco8e1...@my.local.lan:
>

>> Als tussenoplossing zou je de serverconfig kunnen aanpassen (indien
>> mogelijk) zodat de .txt files worden uitgestuurd met text/html als
>> content- type, dan kan de browser ze als HTML beschouwen. Maar dan nog
>> zul je ze moeten aanpassen (alhoewel het waarschijnlijk al genoeg is om
>> <PRE> en </PRE> om de tekst heen te zetten).
>
> Zijn er maar een paar, van die (inmiddels honderden....:)) .txt files,
> die zo breed zijn uitgewoekert, dus als ik dat voor die paar files
> invidueel/handmatig kan doen is het ook goed (en dat <PRE>/</PRE>
> idem)....en/want ergens komt mij dat 'text/html' namelijk bekend voor,
> alsof het ook in de pagina zou kunnen staan?

Nee, dat is niet mogelijk.

> Weet niet hoe diep ik die server-config in moet/kan duiken; het is mijn
> eigen domain, bij hostmonster.com (shared hosting), dat zou genoeg moeten
> zijn, toch?

Het hangt ervan af in hoeverre je de HTTP server configuratie aan kunt
passen. Vaak bieden shared hosting accounts wel een oplossing op basis
van .htaccess.

Als je die kunt aanpassen kan je dit proberen (dat moet je in een
bestand genaamd '.htaccess' zetten in dezelfde directory als de
.txt files):

<FilesMatch "(bestandA|bestandB|bestandC)\.txt$">
ForceType text/html
</FilesMatch>

De bestanden 'bestandA.txt', 'bestandB.txt' en 'bestandC.txt' worden dan
uitgeserveerd met text/html als content type.

--
robert

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkcqt7g...@my.local.lan:

> Willem-Jan Markerink <w.j.ma...@a1.nl>:
>> US3N37+{n.i.w.o}@gmail.com (robert) wrote in
>> news:slrnkco8e1...@my.local.lan:
>>
>>> Als tussenoplossing zou je de serverconfig kunnen aanpassen (indien
>>> mogelijk) zodat de .txt files worden uitgestuurd met text/html als
>>> content- type, dan kan de browser ze als HTML beschouwen. Maar dan nog
>>> zul je ze moeten aanpassen (alhoewel het waarschijnlijk al genoeg is om
>>> <PRE> en </PRE> om de tekst heen te zetten).
>>
>> Zijn er maar een paar, van die (inmiddels honderden....:)) .txt files,
>> die zo breed zijn uitgewoekert, dus als ik dat voor die paar files
>> invidueel/handmatig kan doen is het ook goed (en dat <PRE>/</PRE>
>> idem)....en/want ergens komt mij dat 'text/html' namelijk bekend voor,
>> alsof het ook in de pagina zou kunnen staan?
>
> Nee, dat is niet mogelijk.
>
>> Weet niet hoe diep ik die server-config in moet/kan duiken; het is mijn
>> eigen domain, bij hostmonster.com (shared hosting), dat zou genoeg moeten
>> zijn, toch?
>
> Het hangt ervan af in hoeverre je de HTTP server configuratie aan kunt
> passen. Vaak bieden shared hosting accounts wel een oplossing op basis
> van .htaccess.

Ja, dat ding heb ik, cq daar mag ik met mijn vingers aan zitten....:))

> Als je die kunt aanpassen kan je dit proberen (dat moet je in een
> bestand genaamd '.htaccess' zetten in dezelfde directory als de
> .txt files):
>
> <FilesMatch "(bestandA|bestandB|bestandC)\.txt$">
> ForceType text/html
> </FilesMatch>
>
> De bestanden 'bestandA.txt', 'bestandB.txt' en 'bestandC.txt' worden dan
> uitgeserveerd met text/html als content type.
>

Okay, klinkt goed, gaan we testen....:))

<jump in time>

Lijkt te werken, inclusief wat basale HTML (kleur).

Thanx!


En kan ik ipv specifieke bestanden daar ook gelijk een wildcard plaatsen?

('*' lijkt in geen enkele vorm te werken, noch als enige noch als extra
bestandsnaam)
(zelfs mijn meest basale perl is erg roestig gewordne sinds ik geen
mailinglists meer hoef te configureren....:))

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:
> US3N37+{n.i.w.o}@gmail.com (robert) wrote in

> news:slrnkcqt7g...@my.local.lan:

>
>> Als je die kunt aanpassen kan je dit proberen (dat moet je in een
>> bestand genaamd '.htaccess' zetten in dezelfde directory als de
>> .txt files):
>>
>> <FilesMatch "(bestandA|bestandB|bestandC)\.txt$">
>> ForceType text/html
>> </FilesMatch>
>>
>> De bestanden 'bestandA.txt', 'bestandB.txt' en 'bestandC.txt' worden dan
>> uitgeserveerd met text/html als content type.
>
> Okay, klinkt goed, gaan we testen....:))
>
> <jump in time>
>
> Lijkt te werken, inclusief wat basale HTML (kleur).
>
> Thanx!
>
> En kan ik ipv specifieke bestanden daar ook gelijk een wildcard plaatsen?
>
> ('*' lijkt in geen enkele vorm te werken, noch als enige noch als extra
> bestandsnaam)
> (zelfs mijn meest basale perl is erg roestig gewordne sinds ik geen
> mailinglists meer hoef te configureren....:))

Het zijn reguliere expressies, geen wildcards :) Dus het zou '.*' in plaats
van '*' moeten zijn.

Stel dat je alle bestand* files wilt matchen:

<FilesMatch "bestand.*\.txt$">

Als je alle .txt files wilt matchen kan het korter:

<FilesMatch "\.txt$">

--
robert

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkctnu4...@my.local.lan:

> Willem-Jan Markerink <w.j.ma...@a1.nl>:
>> US3N37+{n.i.w.o}@gmail.com (robert) wrote in
>> news:slrnkcqt7g...@my.local.lan:
>>
>>> Als je die kunt aanpassen kan je dit proberen (dat moet je in een
>>> bestand genaamd '.htaccess' zetten in dezelfde directory als de
>>> .txt files):
>>>
>>> <FilesMatch "(bestandA|bestandB|bestandC)\.txt$">
>>> ForceType text/html
>>> </FilesMatch>
>>>
>>> De bestanden 'bestandA.txt', 'bestandB.txt' en 'bestandC.txt' worden
>>> dan uitgeserveerd met text/html als content type.
>>
>> Okay, klinkt goed, gaan we testen....:))
>>
>> <jump in time>
>>
>> Lijkt te werken, inclusief wat basale HTML (kleur).
>>
>> Thanx!
>>
>> En kan ik ipv specifieke bestanden daar ook gelijk een wildcard
>> plaatsen?
>>
>> ('*' lijkt in geen enkele vorm te werken, noch als enige noch als extra
>> bestandsnaam)
>> (zelfs mijn meest basale perl is erg roestig gewordne sinds ik geen
>> mailinglists meer hoef te configureren....:))
>
> Het zijn reguliere expressies, geen wildcards :) Dus het zou '.*' in
> plaats van '*' moeten zijn.

Ah ja, die punt komt mij nog vaag bekend voor....:))

> Stel dat je alle bestand* files wilt matchen:
>
> <FilesMatch "bestand.*\.txt$">
>
> Als je alle .txt files wilt matchen kan het korter:
>
> <FilesMatch "\.txt$">
>

Okay, nog simpeler, mooi....:))

Gaat getest worden, thanx!

[Willem-Jan Markerink]

"Willem-Jan Markerink" <w.j.ma...@a1.nl> wrote in
news:XnsA12CD284F9CB...@130.133.4.10:

Hmm....nou zou ik zweren dat het voorheen/destijds idd werkte (individueel &
algemeen filter), maar momenteel is het weer een puinhoop, zelfs groter dan
voorheen (1 grote ASCII-brei aan elkaar)....en heb sindsdien toch echt nix
gewijzigd.



<FilesMatch "\.txt$">

ForceType text/html

</FilesMatch>


Ah ja, toch wat gewijzigd....heb dit....


<PRE>
<BODY>
<HTML>

</PRE>
</BODY>
</HTML>

....boven en onder weggehaald, had ik als allereerste poging er neer gezet,
voordat ik met dat FilesMatch in de clinch ging....cq *dus* dacht ik dat dat
wel weer weg kon....niet dus....
(en zou ook zweren dat ik dat als laatste toen nog een keer gecontroleerd
heb....zoveel fidusie heb ik wel in Murphy)
En dat gaat dus nu bij *alle* .txt files fout, ook de niet-te-brede
(bulk)....

Als dit idd betekent dat ik aan elke .txt file alsnog eea aan HTML-code moet
toevoegen, dan werkt het dus niet zoals ik dacht/hoopte (en kan ik het beter
alsnog file-specifiek maken....zo heel veel 'ueber-brede' .txt/ASCII
bestanden heb ik weliswaar niet, maar had het toch graag wat 'toekomstvast'
gemaakt....;))

Nog enig alternatief?

Thanx!....:))

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:

> Hmm....nou zou ik zweren dat het voorheen/destijds idd werkte
> (individueel & algemeen filter), maar momenteel is het weer een puinhoop,
> zelfs groter dan voorheen (1 grote ASCII-brei aan elkaar)....en heb
> sindsdien toch echt nix gewijzigd.

Ik heb even je voorbeeld van destijds erbij gepakt, en die lijkt toch goed
te werken hoor:
http://www.markerink.org/WJM/HTML/tow_NATO-hitches.txt

> <FilesMatch "\.txt$">
>
> ForceType text/html
>
> </FilesMatch>
>
>
> Ah ja, toch wat gewijzigd....heb dit....
>
> <PRE>
> <BODY>
> <HTML>

Die volgorde moet eigenlijk andersom zijn:
<HTML>
<BODY>
<PRE>

Maar dat zal je probleem niet veroorzaken.

> </PRE>
> </BODY>
> </HTML>
>
> ....boven en onder weggehaald, had ik als allereerste poging er neer gezet,
> voordat ik met dat FilesMatch in de clinch ging....cq *dus* dacht ik dat dat
> wel weer weg kon....niet dus....

Nee, dat klopt, die moeten er wel staan om te voorkomen dat de browser de
lange regels af gaat breken.

> En dat gaat dus nu bij *alle* .txt files fout, ook de niet-te-brede
> (bulk)....
>
> Als dit idd betekent dat ik aan elke .txt file alsnog eea aan HTML-code
> moet toevoegen, dan werkt het dus niet zoals ik dacht/hoopte (en kan ik
> het beter alsnog file-specifiek maken....zo heel veel 'ueber-brede'
> .txt/ASCII bestanden heb ik weliswaar niet, maar had het toch graag wat
> 'toekomstvast' gemaakt....;))

Ik heb nog even gekeken of Apache niet een mogelijkheid heeft om zelf die
stukjes HTML boven- en onderaan elke file te zetten, maar dat lijkt niet te
kunnen. Dus dan is het toch ï¿œf elke file aanpassen, ï¿œf de FilesMatch alleen
specifiek op die paar bestanden met te lange regels laten matchen. Dan hoef
je de extra HTML-code alleen in die bestanden op te nemen.

--
robert

[John.R]

Op 13/01/2013 4:42, Willem-Jan Markerink schreef:

> "Willem-Jan Markerink" <w.j.ma...@a1.nl> wrote in
> news:XnsA12CD284F9CB...@130.133.4.10:

>

> Nog enig alternatief?
>
> Thanx!....:))

Als uw server het toelaat,
Server Side Include of SSI

Zet onderstaande in 'n html file

<html><body><pre>
<!--#INCLUDE FILE="tow_NATO-hitches.txt"-->
</pre></body></html>


Voorbeeld
http://www.exoticaroeselare.be/Markerink.html

--
P

[robert]

John.R <inv...@invalid.invalid>:

> Op 13/01/2013 4:42, Willem-Jan Markerink schreef:
>> "Willem-Jan Markerink" <w.j.ma...@a1.nl> wrote in
>> news:XnsA12CD284F9CB...@130.133.4.10:
>
>>
>> Nog enig alternatief?
>>
>> Thanx!....:))
>
>
> Als uw server het toelaat,
> Server Side Include of SSI
>
> Zet onderstaande in 'n html file
>
> <html><body><pre>
> <!--#INCLUDE FILE="tow_NATO-hitches.txt"-->
> </pre></body></html>

Dan blijft het probleem dat 'ie dat voor elke .txt file moet doen.

--
robert

[Rob]

for name in *.txt
do
cat >`basename $name .txt`.html <<EOF
<html><body><pre>
<!--#INCLUDE FILE="$name"-->
</pre></body></html>
EOF
done

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkf4lmf...@my.local.lan:

> Willem-Jan Markerink <w.j.ma...@a1.nl>:
>> Hmm....nou zou ik zweren dat het voorheen/destijds idd werkte
>> (individueel & algemeen filter), maar momenteel is het weer een
>> puinhoop, zelfs groter dan voorheen (1 grote ASCII-brei aan
>> elkaar)....en heb sindsdien toch echt nix gewijzigd.
>
> Ik heb even je voorbeeld van destijds erbij gepakt, en die lijkt toch
> goed te werken hoor:
> http://www.markerink.org/WJM/HTML/tow_NATO-hitches.txt
>
>> <FilesMatch "\.txt$">
>>
>> ForceType text/html
>>
>> </FilesMatch>
>>
>>
>> Ah ja, toch wat gewijzigd....heb dit....
>>
>> <PRE>
>> <BODY>
>> <HTML>
>
> Die volgorde moet eigenlijk andersom zijn:
> <HTML>
> <BODY>
> <PRE>

Wat weet/vermoedde ik, maar dat kwam mij in de copy&paste kraam even wat
minder te pas....;))

> Maar dat zal je probleem niet veroorzaken.
>
>> </PRE>
>> </BODY>
>> </HTML>
>>
>> ....boven en onder weggehaald, had ik als allereerste poging er neer
>> gezet, voordat ik met dat FilesMatch in de clinch ging....cq *dus*
>> dacht ik dat dat wel weer weg kon....niet dus....
>
> Nee, dat klopt, die moeten er wel staan om te voorkomen dat de browser
> de lange regels af gaat breken.

Gatjakkes.

>> En dat gaat dus nu bij *alle* .txt files fout, ook de niet-te-brede
>> (bulk)....
>>
>> Als dit idd betekent dat ik aan elke .txt file alsnog eea aan HTML-code
>> moet toevoegen, dan werkt het dus niet zoals ik dacht/hoopte (en kan ik
>> het beter alsnog file-specifiek maken....zo heel veel 'ueber-brede'
>> .txt/ASCII bestanden heb ik weliswaar niet, maar had het toch graag wat
>> 'toekomstvast' gemaakt....;))
>
> Ik heb nog even gekeken of Apache niet een mogelijkheid heeft om zelf
> die stukjes HTML boven- en onderaan elke file te zetten, maar dat lijkt
> niet te kunnen.

Ja, wilde mij nog niet gelijk op ingewikkelde & Murphiaanse text-edit-
macro's/-scripts storten....die brute oplossing laat ik nog even in de
ijskast staan.
(blijft ook nadien onhandig, want alsnog kan ik niet eventjes flux een
nieuw .txt bestandje in elkaar knutselen, zonder telkens weer aan die
PRE/BODY/HTML tags te moeten denken....)


> Dus dan is het toch óf elke file aanpassen, óf de

> FilesMatch alleen specifiek op die paar bestanden met te lange regels
> laten matchen. Dan hoef je de extra HTML-code alleen in die bestanden op
> te nemen.

Yep, die 'kleine' oplossing lijkt voorlopig de enige die soulaas biedt....

Thanx voor het wederom meedenken/-peinzen....:))

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkf4lmf...@my.local.lan:

> Willem-Jan Markerink <w.j.ma...@a1.nl>:
>> Hmm....nou zou ik zweren dat het voorheen/destijds idd werkte
>> (individueel & algemeen filter), maar momenteel is het weer een
>> puinhoop, zelfs groter dan voorheen (1 grote ASCII-brei aan
>> elkaar)....en heb sindsdien toch echt nix gewijzigd.
>
> Ik heb even je voorbeeld van destijds erbij gepakt, en die lijkt toch
> goed te werken hoor:
> http://www.markerink.org/WJM/HTML/tow_NATO-hitches.txt

Ja, sorry, heb die PRE/BODY/HTML tags daar gelijk maar teruggezet, in
afwachting van een bredere oplossing.

>> <FilesMatch "\.txt$">
>>
>> ForceType text/html
>>
>> </FilesMatch>
>>
>>
>> Ah ja, toch wat gewijzigd....heb dit....
>>
>> <PRE>
>> <BODY>
>> <HTML>
>
> Die volgorde moet eigenlijk andersom zijn:
> <HTML>
> <BODY>
> <PRE>

Wat weet/vermoedde ik, maar dat kwam mij in de copy&paste kraam even wat
minder te pas....;))

> Maar dat zal je probleem niet veroorzaken.

Kon mij dat ook niet voorstellen, en de test gaf mij gelijk (sluit uiteraard
niet uit dat er niet alsnog andere browser(versie)s over kunnen struikelen,
past/present/future, maar dat was nou ook juist *de* reden om helemal *nix*
aan HTML-tags te willen gebruiken....;))

>> </PRE>
>> </BODY>
>> </HTML>
>>
>> ....boven en onder weggehaald, had ik als allereerste poging er neer
>> gezet, voordat ik met dat FilesMatch in de clinch ging....cq *dus*
>> dacht ik dat dat wel weer weg kon....niet dus....
>
> Nee, dat klopt, die moeten er wel staan om te voorkomen dat de browser
> de lange regels af gaat breken.

Gatjakkes.

>> En dat gaat dus nu bij *alle* .txt files fout, ook de niet-te-brede
>> (bulk)....
>>
>> Als dit idd betekent dat ik aan elke .txt file alsnog eea aan HTML-code
>> moet toevoegen, dan werkt het dus niet zoals ik dacht/hoopte (en kan ik
>> het beter alsnog file-specifiek maken....zo heel veel 'ueber-brede'
>> .txt/ASCII bestanden heb ik weliswaar niet, maar had het toch graag wat
>> 'toekomstvast' gemaakt....;))
>
> Ik heb nog even gekeken of Apache niet een mogelijkheid heeft om zelf
> die stukjes HTML boven- en onderaan elke file te zetten, maar dat lijkt
> niet te kunnen.

Ja, wilde mij nog niet gelijk op ingewikkelde & Murphiaanse text-edit-
macro's/-scripts storten....die brute oplossing laat ik nog even in de

ijskast staan....;))

(blijft ook nadien onhandig, want alsnog kan ik niet eventjes flux een
nieuw .txt bestandje in elkaar knutselen, zonder telkens weer aan die
PRE/BODY/HTML tags te moeten denken....)

> Dus dan is het toch �f elke file aanpassen, �f de

> FilesMatch alleen specifiek op die paar bestanden met te lange regels
> laten matchen. Dan hoef je de extra HTML-code alleen in die bestanden op
> te nemen.

Yep, die 'kleine' oplossing lijkt voorlopig de enige die soulaas biedt....

Thanx voor het wederom meedenken/-peinzen....:))

[Willem-Jan Markerink]

"John.R" <inv...@invalid.invalid> wrote in news:kcu6lq$ba5$1
@speranza.aioe.org:

Ja, file-specifiek (opsomming) was ik al half op weg, maar alsnog had in die
(eerste) oplossing een paar HTML-tags nodig....
(die crux had ik niet in de gaten, tot gisteren, nadat ik die tags (als
allereerste eigen (gefaalde) test daar had neergepoot))

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkf5pcd...@my.local.lan:

Yup.
En zo niet voor elke bestaande (valt wellicht nog te behappen met eoa text-
macro/-script), dan toch weer handmatig voor elk nieuw .txt bestand in de
toekomst.

En zelfs zo'n gescripte bulk is link, want vanuit sommige (export)editors
kun je kiezen voor het aanvullen van een bestaand bestand met nieuwe zooi
(oa Pegasus/WinPmail bij email-export), en dan komt die aanvulling onder de
HTML-afsluittags....ook verre van foolproof dus.

[Willem-Jan Markerink]

Rob <nom...@example.com> wrote in news:slrnkf5v6g...@xs8.xs4all.nl:

Zo'n text-script/-macro blijft de minst elegante oplossing, cq is mij
eigenlijk niet foolproof genoeg....niet handig bij aanmaak nieuwe .txt
bestanden, en ook niet bij data-exports die bestanden kan aanvullen, ipv
overschrijven....

En andersom mijn hoofd pijnigen welke .txt files in het verleden zo breed
zijn opgemaakt (en met PRE/BODY/HTML-tags aangevuld moeten worden) wil ik
eigenlijk liever ook niet....:))
(het zullen er niet veel zijn, maar het *totale* aantal .txt files is wel
groot, eerder richting 1000 dan richting 100....;))
(en bestrijken inmiddels eerder 20 dan 10 jaar, dus uit mijn geheugen
vissen welke wel/niet is ook geen optie....:))
(om diezelfde reden (legacy-links van elders) kan/wil ik ze ook niet
categorisch in .htm(l) converteren (en/of mij een bulk redirects op de hals
te halen))

Enfin, interessante casus van een zeer basaal probleem (veel basaler in
HTML-context kan het eigenlijk niet eens....:)), waarvoor de simpelste
oplossingen het minst voor de hand liggen (cq de reflex-neiging naar
complexiteit groot is....;))


Of, om in mijn automotive context te blijven:

'Engine doesn't accept this type of fuel'.

"Then change fuel, not engine."

'But I only have this type of fuel.'

"Then you're stranded."

[robert]

Willem-Jan Markerink <w.j.ma...@a1.nl>:

> En andersom mijn hoofd pijnigen welke .txt files in het verleden zo breed
> zijn opgemaakt (en met PRE/BODY/HTML-tags aangevuld moeten worden) wil ik
> eigenlijk liever ook niet....:))

Als je 'breed' kunt definiï¿œren in termen van 'minstens een X aantal
karakters breed' kan je daar makkelijk naar zoeken (uitgaande van een
Unix-achtige OS):

grep -l '^.{100,}' *

Dat laat files zien met in ieder geval ￜￜn regel van minstens 100 karakters
breed.

--
robert

[Rob]

Willem-Jan Markerink <w.j.ma...@a1.nl> wrote:
> En zelfs zo'n gescripte bulk is link, want vanuit sommige (export)editors
> kun je kiezen voor het aanvullen van een bestaand bestand met nieuwe zooi
> (oa Pegasus/WinPmail bij email-export), en dan komt die aanvulling onder de
> HTML-afsluittags....ook verre van foolproof dus.

Je hebt kennelijk nog niet begrepen hoe die INCLUDE werkt en hoe dat
in jouw geval ingezet kan worden.

[Willem-Jan Markerink]

US3N37+{n.i.w.o}@gmail.com (robert) wrote in

news:slrnkf7984...@my.local.lan:

> Willem-Jan Markerink <w.j.ma...@a1.nl>:
>> En andersom mijn hoofd pijnigen welke .txt files in het verleden zo breed
>> zijn opgemaakt (en met PRE/BODY/HTML-tags aangevuld moeten worden) wil ik
>> eigenlijk liever ook niet....:))
>

> Als je 'breed' kunt defini�ren in termen van 'minstens een X aantal

> karakters breed' kan je daar makkelijk naar zoeken (uitgaande van een
> Unix-achtige OS):
>
> grep -l '^.{100,}' *
>

> Dat laat files zien met in ieder geval ��n regel van minstens 100 karakters
> breed.
>

Ja, die gedachte kwam reeds in mij op toen ik het schreef....;))

Maar ik blijf dat een ietwat brute/non-elegante oplossing vinden ('end-of-
pipe-solution'?)....want dan kan ik nog steeds niet argeloos-vrolijk nieuwe
.txt bestanden optuigen, zonder telkens aan die PRE/BODY/HTML te moeten
denken....;))
(lees: nog steeds niet 100% foolproof)
(en ook niet bij data-export die een bestand aanvult ipv overschrijft)
(gebeurt niet vaak, maar je zult zien dat ik juist dan die reeds bestaande
tags vergeet)

[Willem-Jan Markerink]

Rob <nom...@example.com> wrote in
news:slrnkf7ifm...@xs8.xs4all.nl:

?
Da's toch iets dat ik _per (desbetreffende) file_ moet doen?
(en *in* de file, niet globaal, voor 1 hele directory, zoals .htaccess dat
doet?)

(en zoals ik nu voor tow_NATO-hitches.txt nog steeds heb staan)

En (latere) data-export die toevoegt ipv overschrijft vernaggelt dat (dan)
sowieso....en het blijft een 'pro-file' oplossing, ipv een globale....

>> <html><body><pre>
>> <!--#INCLUDE FILE="tow_NATO-hitches.txt"-->
>> </pre></body></html>

Cq als het (idd/hopelijk) wat anders/globalers is dan mis ik eigenlijk nog de
naam van het bestand, zodat het op eoa manier door de server herkent wordt
(en toegepast op de desbetreffende file(s)), en ook hoe daar wederom een
'wildcard' in te knutselen is....;))


Ik laat mij graag van het tegendeel overtuigen....;))

[Willem-Jan Markerink]

"Willem-Jan Markerink" <w.j.ma...@a1.nl> wrote in

news:XnsA1489F028D13...@130.133.4.10:

Omgekeerde oplossing, baserende op het eerdere, wel-werkende, concept van
Rob (maar de non-PRE/BODY/HTML-tagged .txt files vernaggelend):

<FilesMatch "\.txt$">

ForceType text/html

</FilesMatch>

Als ik de desbetreffende files (ook toekomstige) wijzig in iets met
xxxxxxxx_wide.txt, en daarop match (en die voorzie van PRE/BODY/HTML, dan
laat ik de overige files met rust.


Euvelig is wel weer dat ik de legacy vernaggel, oude links elders....
(en met *daarvoor* weer eoa filterende/matching redirect krijgt het toch
nog weer een hoog houtje-touwtje gehalte....;))

Elegant (lees: overzichtelijk, en na 5 jaar ook nog inzichtelijk) wordt het
hier volgens mij nooit....8-))

(maar goed, dat is het bij echte legacies & oeroude notariele stukken ook
zelden....:))

[Rob]

Willem-Jan Markerink <w.j.ma...@a1.nl> wrote:
> (en met *daarvoor* weer eoa filterende/matching redirect krijgt het toch
> nog weer een hoog houtje-touwtje gehalte....;))

Als er IETS een hoog houtje-touwtje gehalte heeft dan is het wel
jouw manier van website bouwen.

Ik zou zeggen verdiep je eens in de materie en pleur de boel in een CMS.

[Willem-Jan Markerink]

Rob <nom...@example.com> wrote in news:slrnkf88u6...@xs8.xs4all.nl:

> Willem-Jan Markerink <w.j.ma...@a1.nl> wrote:
>> (en met *daarvoor* weer eoa filterende/matching redirect krijgt het toch
>> nog weer een hoog houtje-touwtje gehalte....;))
>
> Als er IETS een hoog houtje-touwtje gehalte heeft dan is het wel
> jouw manier van website bouwen.

Tja, legacy is legacy....:))
Overigens distantieer ik mij van de term 'bouwen'; dat suggereert eoa
vooropgezet doel, en, godverhoede, plan....:))

> Ik zou zeggen verdiep je eens in de materie en pleur de boel in een CMS.
>

<gruwel>

a) bestonden die destijds helemaal niet, en b) bestaan die over 5-10 jaar
ook niet meer in dezelfde/compatible vorm, en c) hecht ik zeer aan WYSIWYG
(niet in de laatste plaats juist in de context van b!).
(ik wordt ook echt *strontziek* van het steeds maar weer moeten updaten van
steeds zwaardere browsers om ueberhaupt andermans content te kunnen blijven
zien....ongeacht hoe rudimentair ASCII-simpel die content defacto is/had
kunnen zijn)


Willem
(de letterlijke vertaling van Notepad behoeft toch ook geen
toelichting?....;))
Jan


PS: denkt nou niet dat ik uw inspanningen niet waardeer; ik ben er alleen
nog steeds niet 100% van overtuigt dat er niet toch nog eoa
slimmere/globalere truc bestaat....;))


Circumvention is much more interesting than convention....;))