Jump to content
Due to limited staffing, chat support will be unavailable from Thursday, July 2 at 5:30 PM (CDT) to Monday, July 20 at 8 AM (CDT). This will allow us to reply to your email requests as quickly as possible. Thank you for understanding. ×

Andrei Thorp

Evernote Employee
  • Content Count

  • Joined

  • Last visited

Community Reputation

20 Neutral

About Andrei Thorp

  • Rank
    Evernote Employee
  1. Hello sir, Yes, we're still working on it. It's not as simple as it sounds -- a pre-requisite is a big overhaul of a lot of the editor code. I've been going through that with my team for the last year and a half. Sorry, I know that's not super satisfying -- but yes, we're still actively working on it, as part of the larger editor project.
  2. Which, IMO, is a good feature. For some reason due to the differences in the way Windows and Mac display fonts, I have found that Verdana 14pt on the Mac is about the same as Verdana 12pt on Windows. So I have set my EN default fonts accordingly. For the most part, the EN iOS display (of Notes from EN Mac/Win) comes across OK. But I wish we could set default font in EN iOS, and control/change fonts. Yeah. On Mac, we actually use pixel fonts, and 14px = 14pt. However, on Windows, 14px actually equals about 12pt, as you noticed. Now, you might say, "what? why? what?" Basically, Microsoft made some very questionable decisions a long time ago, and now they're stuck with them. You can read more about it here -- https://www.evernote.com/shard/s20/sh/9d99a8ee-3cb0-4e3d-9b6f-99d3984ff5f9/16a6c350d856f24a-- which I clipped directly from the Microsoft Developer Network. With respect to iOS font settings -- noted.
  3. Yeah, for sure. That's why it's a big deal that we're rolling out this new beta editor on Windows right now. It means that the same editor that's being used to edit and display notes on Mac will be used on Windows. We think this'll make formatting differences largely disappear, at least between these two clients. The one exception would be the default font, which varies by platform -- but that's a feature.
  4. It doesn't seem like there has been any public-facing progress on this issue in the 6 months since it was discussed here. Are there any updates? Yep, for sure. For example, the latest Windows betas have had an updated editing experience that's basically identical to the Mac editing experience now (with a few kinks still being ironed out). My team is continuing to work on it.
  5. Yeah, I agree. I will definitely keep working on making sure that editing and viewing is totally consistent going forward. You're right, users' formatting should be sacred. Has there been any update on this? Just curious if the devs are working toward making formatting consistent between clients or not. Currently, iOS and Mac still have different spacing, which means your notes look incorrect on one platform at all times. It's going to take some time to make all these small details the same across the board, since we're working with so many different client teams. There has been a lot of progress on this (it's actually my main project right now), but I'll have to be quiet about the specifics for now.
  6. Thanks for that. I'll take a look. Still, this'll be largely handled if we do add automatic margins back.
  7. Yeah, I agree. I will definitely keep working on making sure that editing and viewing is totally consistent going forward. You're right, users' formatting should be sacred.
  8. For what it's worth, <div>s are extremely standard, perfectly supported in all browsers, and are extremely common to see in all sorts of webclips, articles, and pages. Overall, they're probably the most consistent and well-defined HTML elements. In effect, using <div>s instead of <p> tags is essentially the same as using <p> tags with manually set margins, as you suggested. Copy-paste compatibility is less of a concern, since copy-pastes tend to hop through an HTML->RTF conversion or an HTML->HTML conversion as they happen (i.e. it doesn't matter too much what our internal representation is, as long as the outside world sees things as it expects. Of course different programs expect different representations, but that's a different problem.) That said, I'll consider our options some more, and I appreciate your thoughts.
  9. Users have been complaining about that layout for years, too. It's one of the assumed complaints about EN - the way lists have spacing before/after them yet standard paragraphs don't. I've read the complaints about this so many times on this forum it's crazy! I'm beyond excited this is being fixed, as I think it's better and more consistent to have everything single-spaced from each other and add spacer lines as desired versus having some things single-spaced and some having block styling. Now to just get text-wrap... Yeah, this is for sure the motivation for this change. I've been an avid Evernote user on many platforms for many years also, and it was always super strange to me how you'd have to remember to add newlines between paragraphs, but definitely avoid adding newlines between paragraphs and lists -- since lists automatically add space. By text-wrap, do you mean text wrapping around floating images? This is easy to answer, and can be found on these forums as well - Evernote is developed platform-specific. Love it or hate it, but each team works on things not 100% parallel with each other. Evernote has 0 track record (as far as I know) of having core capabilities only on one platform (they might have a gap between implementations, but they all get everything eventually), so I wouldn't worry. Dollars to donuts, it will all be consistent eventually (according to track record). Yep, you nailed this one too. I'm definitely working quite hard to try and improve the consistency of note editing/viewing between platforms.
  10. I've queried the devs of all the other platforms to see what kinds of default spacing they're adding to notes. It is kind of inconsistent from place to place, but I'll work on improving that. Mac is the only platform currently that doesn't add space to these elements, so I feel like a compromise there is probably a good idea. One of the good things about the new editor is that it doesn't use paragraph or heading tags itself (it does most formatting using <div>s instead). This means that I can potentially add some default spacing around <p> and <hX> without affecting notes that users type directly in the new editor. However, lists are still created as real HTML lists, so I won't add default spacing around them. Hopefully this is a good enough compromise for you.
  11. Can you elaborate more on this one? I'm not 100% sure I get it. Would also love to see an exported note that exhibits this behaviour. And no, unfortunately, our bug tracking system is internal-only.
  12. Unfortunately, maintaining the old editor in parallel took away too many human hours from trying to polish the current one, so we had to drop it. Do you have any active backwards compatibility issues (aside from this one)? I'm under the impression that we've done a great job supporting old notes and webclips, but I'd love to hear your side of it.
  13. Hello Kevin, I'm from the team that created the Mac v6 editor. I'm very sorry to have disrupted your workflow, and we've been working internally for a few days to come up with a decent solution. I've inspected the sample note that you've given us, and it doesn't actually specify any extra space between pieces of text. The real cause of this issue was that we decided to experiment with getting rid of the default whitespace that web browsers add to HTML tags like <p> and <h1>. As a result, you haven't been seeing this added space. In general, we believe that this decision has created a more predictable editing experience, but it unfortunately did break some stuff for users that were relying on the old behaviour. Don't worry, we haven't lost any of your data or actually changed any of your old notes. It's just a note presentation issue. I'm still trying to figure out what the best compromise is, but I just wanted to let you know that I'm actively looking at it.
  • Create New...