Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ljensen1

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Thank you both for your suggestions. I'll give the Insert from URL script a try. Ben, my URL leads to a php page that can either (depending on how I code it) 1) create a pdf in the browser, or 2) create the pdf and open the "Save As" window so the pdf can be downloaded. If I use SCSetContainer, do you know if I would end up with the pdf or the code?
  2. I use tpdf to create pdf files from a FileMaker database. This results in a URL that opens the "Save As" dialogue box. I would like to have a FileMaker script that will opens this URL and automatically saves the pdf to a programmed-in location. Will SuperContainer do this?
  3. I got an answer off the forum and thought I would add it here in case it helps anyone. I just needed to use the encoding function in FX.php: $find_lang->setCharacterEncoding( 'UTF-8' ); to make sure the data going into and out of FileMaker is UTF-8. That function wasn't available years ago when I started using FX.php, and I didn't notice it had been added. Glad it ended up to be something easy. I also had to switch from fpdf to tcpdf so I could use a unicode font and the characters would show up correctly on the pdf's. I had actually known I would have to do that, but I wanted to get the FileMaker part straightened out first.
  4. More information. One of the characters that comes across as a box is "򢀓" (at least that is how it is rendered when sent to fpdf). The user entered this as an emdash (—) in text pasted from Microsoft Word. When FileMaker sends the data back to the web, the emdash becomes "򢀓". The same thing occurs if the Microsoft Word text is pasted directly into the database rather than entered through the web. When I look up "򢀓" here: "http://www.fileformat.info/info/unicode/char/a2013/index.htm, this is said to be NOT a valid unicode character. Why is FileMaker returning data like this? Or is it php or XML (I'm using FX.php)?
  5. I have further information that may be helpful: This is the problem scenario: 1) User pastes something into a web form (probably from Word) 2) Web page sends data to FM13 database, using FX.php. 3) Data looks fine in FM13- no problem with emdashes, smart quotes, etc. 4) FM13 database sends data back to web page using FX.php (this is where the problem occurs). 5) On web page, user sees boxes instead of certain characters. However, if I leave FM13 out of the loop and do the following, the web page displays the characters without a problem: 1) User pastes something into a web form (probably from Word). 2) Data is passed to a new web page using $_POST 3) Characters display properly. So the problem seems to lie in how FileMaker is returning these characters to the browser.
  6. Yes, that is exactly what I have on every web page: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> I tried that function, but still have the same issue. The latest problem, for instance, is a dash showing as the funny box character in the browser, and then showing as "&#663571;” by a pdf created through fdpf. My solution is to add another substitution to my php function and change "&#663571;” to "&#8212;" before it hits the browser. This is not a good solution because I only find these problems as users complain.
  7. Unfortunately that did not work. I still get "funny" characters when viewing the inputted data through the web (Firefox, in this case). Em-dashes and smart quotes appear as a small box with 6 digits of some sort inside of the box - three on the top and three on the bottom.
  8. Thank you. I will try that. Sorry I didn't get back to this sooner - I get caught up in another project.
  9. I have a web-based page that allows a user to paste information into a text field. This data is sent to FileMaker 13 using FX.php. When returned, so the user can preview what was entered, some of the glyphs appear as empty boxes in Internet Explorer, or number-filled boxes in Firefox. This includes various quotes, apostrophes, emdashes, etc. I don't recall this problem before we moved up to FM13. The data looks fine within FileMaker itself. The web page uses a font family of Verdana, Arial, Helvetic, san-serif. I've tried creating the text in a variety of different fonts before pasting into the web page, and have the same result each time. Right now I have a php function that replaces html entity names so the characters will appear correctly, but that isn't a great solution because I'm always finding more problem glyphs. Does anyone have any suggestions? Below are some the html entities that give me problems: &#663572; (I replace with &#8212;) //emdash &#663580; (I replace with &#8220;) // left quote &#663581; (I replace with &#8221;) // right quote &#663577; (I replace with &#8217;) // apostrophe &#663571; (I replace with &#8212;) //emdash &#2031613; (I replace with &#8212;) //emdash &#663576; (I replace with &#8217;) // apostrophe
  10. Is there any way to format the body of an email using the Send Mail script step? (FileMaker 11)
  11. I'm trying to collect email addresses across a found set. I'm using SMTP-it and I want to BCC to a large group of people. Maybe there's a way to get SMTP-it to do this, but I've haven't found it.
  12. Thank you. I'll take a look at this is more detail and let you know how it goes.
  13. Is there a function that will automatically collect all the values in a particular field over a found set? The Send Mail script does this when you pick "Collect addresses across found set," but I can't figure out how to get the database to do it for my own purposes. I know I can loop through the records, but I'm looking for something quicker. Field index doesn't work because that doesn't limit the values to the found set.
  14. Eventually, we'll be able to upgrade - but for now I've got to work with what we have. Does FM9 allow more than 100 web clients, or is that just possible because you split it over multiple machines?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.