hi,

having got to the point where all I can see is a persistent quirk through 20 or so variations...

the input is a file name in format: 1-some-file-name.html

the desire is to calculate a link output with the scrubbed anchor text in Title Case:

Some File Name.html

the problem is every variation returns a lower case first word of the anchor text:

some File Name

the current calc variation:

Let([

FN = file_name ;

Aopen = "" ;

// remove the leading number, remove the dash separators, remove the .html suffix

ATXT = Trim( Substitute( FN ;[Left(FN; 1); ""] ; ["-" ; " "] ; [".html"; "" ] )) ;

ANCH = TextStyleAdd ( ATXT ; Titlecase) ;

Aclose = ""

];

Aopen & ANCH & Aclose

)

Try:

ANCH = Proper ( ATXT ) ;

Your version doesn't work because there is no space between ">" and "some" - so the style doesn't consider the "s" as the first character in a word.

thanks Comment, that corrected it.

I had looked at the individual components, and the ANCH part returned the required on its own, but as soon it was included in the full calc... around and around one went.

e.g. this returns Some File Name

Let([

FN = file_name ;

Aopen = "" ;

ATXT = Trim( Substitute( FN ;[Left(FN; 2); ""] ; ["-" ; " "] ; [".html"; "" ] )) ;

ANCH = TextStyleAdd ( ATXT ; Titlecase ) ;

//ANCH = Proper ( ATXT ) ;

Aclose = ""

];

//Aopen & ANCH & Aclose

ANCH

)

Yes, it's a matter of WHEN is the applied styling actually rendered. This happens only at the layout level, AFTER the text has been concatenated.

The other thing is, you probably should have been using Proper() anyway, since it seems like you intend to export the result to a plain text file - and any styling will be lost in the process.

BTW, exporting data to HTML is best done by exporting as XML with a custom XSLT stylesheet. The stylesheet can take on the entire process and free the file from all kinds of awkward calculations that are used only for exporting.

I had initially tried exporting, but the process mutated the character encoding (it was concluded)

So now I create a blank html file using

"touch " & $_path & $_file

into applescript

compile the html template, assemble the database data, and insert into html file code,

then "pbpaste > " & $_filepath through applescript again

C

the process mutated the character encoding

:qwery:

Some extra invisible characters are inserted at the very start of the file when export field contents is used; these characters are evident in SEEdit ( a mac XHTML editor) but not in Coda ( another editor), TextWrangler or Smultron. The characters cause validation to fail. At the time I was working this up, a couple of months ago, I was only using the output in SEEdit. I just now ran the code opened in SEEdit and Coda separately through the W3C validator, and the SEEdit received code : ��

Ah, you were exporting field contents. This always results in a UTF-16 encoded file. But that's not what I suggested.

as multiple attempts at post a reply borks at the code whether Use None is specified (option remains = markup on) or wrapped in code, the details are in the attachment

But basically, FM export as field contents effects character encoding as UTF-16LE, which mutates the input processed by my preferred XHTML editor, and causes validation to fail.

Some extra invisible characters are inserted at the very start of the file when export field contents is used; these characters are evident in SEEdit ( a mac XHTML editor) but not in Coda ( another editor), TextWrangler or Smultron. The characters cause validation to fail. At the time I was working this up, a couple of months ago, I was only using the output in SEEdit. I just now ran the code opened in SEEdit and Coda separately through the W3C validator, and the SEEdit received code

export_field_contents.pdf

I know; XML with a custom XSLT stylesheet

I could not get my head around it at the time (months ago). could not see past all the additional tags that had to be stripped out. Still can't.

I have clean assembled code, all I do now is pbpaste it into the target file(s)

The way I read it, validation fails because the file is UTF-16 encoded but declares iself as UTF-8.

I think the difference you see between different text editors is due to which opinion they choose to follow: if they decide it's UTF-8, then there are "extra characters".

No I was assuming (and thought I had tested) validation fails because of the leading 2 question marks on black diamond characters (unrecognised character glyph?)

If these are deleted from the start of the prologue, the code should validate, but it doesn't, the validation returns just a < character , so something is still going on.

I also tried changing the code in the FM field to UTF-16, the export field contents remains the same; two leading (?) characters that cause the validation to fail.

Edited October 27, 201015 yr by Guest

Those two characters are part of UTF-18 encoding. If you open the file using UTF-8 encoding, then the characters are assumed to be part of the text, and an attempt is made to render them on screen.

Deleting the characters does not change the file's encoding (though I imagine it messes up the original UTF-16); to change the encoding properly, open the file in TextWrangler/BBEdit, select the desired encoding (pop-up at the bottom of the window) and re-save the file.