Greg, I think it doesn't matter *what* you use to display the static map, whether it be Firefox, a custom made dumb browser with no buttons or Outlook Express. What matters is *how* you load it, and *who* can load it.
There are two ways to embed an image in an HTML email: 1. Same as in a web page, with <img src="http:// ... > 2. As an inline resource, and I don't remember the exact syntax for that, but is something like <img src="cid:img1> where 'img1' is the first image attachmed to the email. With mode 1, the image is online, on some internet server, which could be google.com, and it is fetched using the HTTP protocol when you open the email. With mode 2, the image travels together with the email as an attachment and gets stored in the recipient's hard drive, and you can view it even if you disconnect from the internet after receiving the email. Outlook Express, or any other desktop mail client could just as well be a custom application that anyone wrote. I believe that mode 1 is OK, while mode 2 is not. The more relevant part of the ToS may be the "Freely Available". If I can subscribe to receive those emails free of charge, and the static maps are embeded as described in mode 1, then I think Bjorn is OK. Disclaimer: IANAL. :-) -- Marcelo - http://maps.forum.nu -- On Oct 23, 6:57 pm, Gregory Short <[email protected]> wrote: > On Oct 23, 2009, at 11:38 AM, Marcelo wrote: > > > > > On Oct 23, 6:26 pm, Gregory Short <[email protected]> wrote: > > >> Except web browser != html viewer... > > > Quite right, but 'HTML viewer' == 'Browser Control', which is commonly > > used in desktop applications written in VB, Delphi, C++, etc., and > > that is allowed. > > What you may not do is to embed the image with a resource ID, because > > that means that you're displaying an attachment inline rather than > > fetching the image by HTTP. > > True enough...I suppose it's just a matter of *who* is telling the > email client the url to fetch. The end-user can't do it, but the > person crafting the email can, and by those means it *can* be directed > to an arbitrary url. Although I'm not entirely convinced that your > equality is entirely true, on account of the question of what happens > when you click a link. In a "regular" browser control, if you click a > link, it's followed in that control (in general). On the other hand, > email clients generally strictly render the html, but provide no > support for interacting with it beyond opening a clicked link in an > actual web browser. The only thing preventing a user from visiting, > for example, google.com in Random Desktop App A is that there is no > way to type in a url, and there are no links to let the user escape > the network of documents prescribed by the developer. Whereas with a > mail client, even if there is a link to google.com, clicking it will > *not* open it in the email client. I'm sure there's a counter-example > out there, of course, but showing that an email client *can* act as a > web browser does not mean that all email clients *do* act as web > browsers. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-maps-api?hl=en -~----------~----~----~----~------~----~------~--~---
