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


Evernote Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Jay-Bob

  1. 6 minutes ago, WeCanLearnAnything said:


    I have exactly the same version of Evernote and deal with the very same types of delays, though sometimes the wait time is longer than a second.

    What's with all the new lag?

    Thank you all for reporting this - the development team is aware of it and are investigating.

    • Like 1
    • Thanks 2

  2. 3 hours ago, lpuerto said:

    By the way... I've notice that the rendering of some captured pages is different in 7.0.2 and 7.1 beta 1. 

    Thank you, I can reproduce the rendering discrepancy between versions with that clipped webpage. I've reported this to our developers.

  3. 56 minutes ago, bshannon said:

    I'm not a big Twitter user but I gave it a try.  Thanks.

    Hi @bshannon, thanks for reporting this. It sound like an issue our development team is aware of and should be fixed in a forthcoming update. If you'd like to DM me an exported copy of the note that shows blank, I can test it for you to make sure that it shows correctly in future versions of the application.

    Otherwise, while not ideal, the note should show correctly on Evernote Web, and if you stay up-to-date with the app, it will be fixed in future updates.

  4. I definitely see the frustration with fonts when switching between mobile/desktop platforms. It sounds like this may be due to Windows having explicit font settings (10,12,14 etc..) and iOS having implicit font settings (Small, Medium, Large). When switching between font sizes in these scenarios across each platform, it can sometimes lead to unexpected results. 

    While not ideal, a possible workaround would be to set your desired font size on Windows and to not change back and forth between Small, Medium, Large on iOS (keep it on the default while editing notes created on Windows), as this might sync back to Windows with an unexpected size.

    If you're performing different actions or steps that cause the unexpected behavior you're seeing, please do let us know the exact steps you're taking and what you're seeing.

    The development team is investigating how to more appropriately handle the size adjustments between clients in the future, but I don't have an estimate on when to expect this.

  5. 18 hours ago, lhb said:


    You're commenting on the reported behavior, which I would classify as a bug. 

    Is your description a description how it _should_ work? Is this the new behavior? Because this behavior is much different than before,  and different than on other platforms. Yet, I find it still the same way in the release version....

    Looking closer at the behavior across Mac, iOS, Windows, you are correct - it's a bug. 

    Simplify Formatting should remove the clipped article's font type, font size, font color, and background html back to Evernote's defaults. All other formatting should be preserved.

    When Simplify Formatting cleans up the background html of a web clip, it is expected to possibly see a slightly altered layout but it's goal is to try to change as little as possible of the original layout.

    Our devs are aware of this and are working on getting Simplify Formatting back to what you expect. I do not have an estimate on when to expect this. 

    In the meantime, while not ideal, please continue to work around this on Windows by either first clipping in "Simplified Article" or use "Remove Formatting" after the clip to get the formatting you expect.

    Thanks for reporting this and sticking with it! Much appreciated.

  6. 4 hours ago, Alex Krylov said:
    • First image is original web page clip.
    • Second — after “Simplify Formatting”
    • Third — after “Remove Formatting”

    I suppose something is wrong. No formatting is removed, but some pieces of the text are changed a bit.

    2018-02-07 17_20_26-All Notebooks - alx.kry@gmail.com - Evernote.png

    2018-02-07 17_21_03-All Notebooks - alx.kry@gmail.com - Evernote.png

    2018-02-07 17_20_51-All Notebooks - alx.kry@gmail.com - Evernote.png

    When I clipped this as "Full Page", the original clip looks similar to yours.

    When I ran Simplify Formatting on the note, it removed some of the extended layout of the page so it better fit into the note window (a few things appeared to move around) but the text in the note stayed as it was on the original website (Helmet 9).

    When I un-did that setting and then ran Remove Formatting, the layout again changed a little to fit better into the note window as opposed to the original clip, and the text in the note changed to the default font (Segoe UI 10). Hyperlinks, headers, and images all stayed in the note.

  7. 19 hours ago, Ethan Mings said:

    The editor is still very hard to manage.

    1. The *tab command for a bullet list does not work.
    2. It so slow to edit or create a note in.  I can hear my typing and watch for the editor to catch up
    3. I've tried things with the Automatically format text elements off, on and off.  Still no real improvement

    Not sure what is happening with the editor.

    It is frustrating.

    1. If you try *space does that get you a bullet list? (Make sure the option is also checked in Tools > Options > Note > "Start a numbered list with "1." or a bulleted list with "* "

    2. If you create a new notebook that is not shared and create a new note, is that new note still slow to create and type in? If you change your view to "Card View" (Ctrl+F6), does that help?

    3. Do you have any notes that are larger amounts of text/attachments (i.e. 9,000+ words, a long clipped note etc)? You can click the view icon in the note list and then "Sort notes by"  and select "Size", then set the sort order to show the largest size notes first. This won't necessarily find the longer-worded notes, but it's a good place to start for the largest size notes and work down from there. Usually it's a note or notes that are longer appearing somewhere in the note list that cause the performance decrease. Finding that content and breaking it up should improve performance. If these steps don't help you discover the cause, please open a new support ticket and we'll take a closer look with you.

  8. On 2/3/2018 at 8:26 AM, lhb said:

    I reported in this forum problems with "Simplify Formatting" for an earlier beta. I'm now working with (306679) Prerelease (CE Build ce-1.39.4193).

    "Simplify Formatting" does not seem to do anything or much.

    "Remove Formatting" does now seem to do something like "Simplify Formatting" before, ie, it changes some formatting, but not to my default fonts, and it leaves all the hyperlinks in.

    I'm still clueless about the directions of this, and what the intended directions are. I often clip from the Web and would like to convert the articles into my simple-to-read formatting with default font, leaving the hyperlinks intact, and I used quite successfully "Simplify Formatting" in the past, although in the last year or so titles and section headers were at different sizes in formatting with funky spacing that could not really been formatted further with any of the editing, something I attributed to upcoming changes in the editor that would ultimately support that kind of thing. Maybe along with the promised Markdown functionality.

    Please try do define clear actions for "Simplify Formatting" and "Remove Formatting" and do keep those consistent.

    Simplify Formatting is not expected to visually change much. It's intention is to remove background html that came over from a copy or clip that could cause issues with further editing. If it's doing it's job right, you shouldn't notice much of a change at all after applying it.

    Remove Formatting on the other hand, is supposed do just that, remove formatting back to defaults and leave hyperlinks active.

    It sounds like from what you'd like to accomplish, it may be best to clip from the Web Clipper using "Simplified Article" to not need to have to later apply Simplify or Remove Formatting.

    • Like 1

  9. 1 hour ago, Vincent Noel said:

    Something that's been giving me grief for a while : drag-n-drop an image file (e.g. PNG) in a note. Now drag-n-drop the same image file to the desktop. Instead of an image file, I get a file called "Untitled clipping" that I can't do anything with. This is very unconvenient.


    Evernote mac Version 6.14 Beta 2 (456074 Direct)

    Yes, if you click in the note editor first and then click and drag to select the image it will turn completely blue, and when you drag and drop to the desktop you'll get the untitled clipping. This is something the developers are investigating, but I don't have an estimate on a fix.

    However, if you click once on the image and get the blue border outline, you can then successfully drag the image to the desktop. Definitely not the most intuitive for all workflows, but you should be able to get the image out of Evernote without having to enter into image gallery.

    Here's an example:


    • Thanks 5

  10. On 12/20/2017 at 6:51 AM, cameronreilly said:

    Since Version 6.14 Beta 1 (including the new new beta 1), I find that when I paste some content into a sentence, the cursor moves to the end of the sentence - not to the end of the pasted section. Is this a bug? Or a new feature? Can I turn it off?

    This is an issue our editor developers are aware of. It appears to be fixed and should be available in a future update (no ETA right now). Thank you for reporting this!

  11. 13 hours ago, Ramkumar LS said:

    If the purpose was to remove the formatting and paste as text only, then sir, why do I get this "*" w/h  makes the whole process unfriendly. Now we have to spend more time on removing the "*" and do the bullets again. If 'paste and match style' is intended to paste the text only, then allow only the text alone to be pasted and let the user to do whatever they want as either adding bullets or leave it as it is.. But having an "*" ruins the either way. One could not leave the text as it is  or have a bullets also!

    Thanks for the comments - I've filed this as a feature request with the development team to take another look at the behavior.

  12. 5 hours ago, Ramkumar LS said:

    Hello Madam, I have updated to the new version 6.8. In the new version I'm not able to 'Paste and Match Style' as I used to do before. Before when I copy a bulletined note from MS Word, if I paste and match style, it automatically used to come in a bulletined format. But now it is not formatted properly and there's '*' comes in every line and it's not aligned also properly. I have attached the two screen shots, in w/h 'image 1' is what I'm facing right now and 'image 2' is what I supposed to get or I used to get in previous version. Is it a bug or anything else. But other members did not highlight this issue here. As I use Evernote for note-making purpose, I think I have found this or only I'm facing such issue?! Please help me sir. This makes it very hard to use Evernote as I have to format text each and every time I copy-paste a text. Thank you.

    The current expected behavior when pasting bullets from Word and pasting into Evernote with paste and match style is to remove the formatting and paste as text only. This means you will see a "*" to represent in text there was a bullet pasted from the external app.

  13. 1 hour ago, Joe F said:

    Since release 6.13, text copied from an EN note to the same note or another note will on occasion end the paste text with nbsp& (non-breaking space code). Has anyone else experienced this behavior? Current version is 6.13.1

    Thanks for mentioning this, we've heard some other reports of it as well. Our devs are aware and it should be fixed in a future update.

  14. 9 hours ago, Garzfoth said:

    Now when you paste anywhere inside a paragraph (except at the very start or very end of it), the cursor immediately jumps all the way to the very end of the paragraph after the text is pasted (instead of remaining at the end of the newly-pasted text, which is the correct behavior and the way it used to work). This is extremely annoying. Am I the only one with this bug or are other people seeing this too?

    The couple of other annoying issues that I have noticed so far have already been mentioned before in this thread and acknowledged by the developers.

    I don't see what all the fuss is about w.r.t. the current syncing behavior — it's working perfectly fine for me, and I actually prefer more frequent syncing...

    Thanks for reporting this. I can definitely see where that's frustrating. Our developers are aware of what you're experiencing and are working towards a fix.

    • Like 1

  15. 11 hours ago, keisoko said:

    It seems that I am unable to use the numbered list format inside the code block to represent line numbers in Beta 4. Even switching between notes, as I was able to do in Beta 3, does not work anymore. If I apply numbered list to the pasted source code first, I then cannot use code block format.

    The intended behavior of code block is to only allow formatted text and rich links. In previous versions of the app you may have been able to place other items into code block, but that was not the intended behavior.

    Going forward these items will not be able to be placed into code block:

    1. Lists
    2. Todos / checkboxes
    3. Horizontal rules
    4. Tables
    5. Attachments
    6. Images
    7. Encryption blocks
    8. Additional code blocks within a code block
    • Like 2

  16. 34 minutes ago, Eduardo Estefano said:

    Yes, the new tables are great looking. But they leave a huge gap on the top and the botton. Before this new feature, I used a single cell table as a title, like when you merge notes. But now it looks horribly, with a huge empty space after the title.


    Thank you for this feedback. The empty space is for the table UI elements, and then there's a blank line above (and below) that to ensure you can get the cursor ahead of and behind the table. Our text editor team is taking all the feedback of the new tables into consideration, so this is appreciated.

  17. The intended behavior of code blocks is text only. This means no bullet/numbered lists, todos, horizontal rules, tables, images, encryption. On certain versions of the app, it was possible to add these options to code blocks but in future updates it will be text only.

    There have been fixes and updates to code block that will be available in the forthcoming updates. This should address the "double code blocks" and paste and match style issues. Please keep your app updated, and if you notice any outstanding issues after the update, please open a support ticket and we'll gladly assist you further.

    • Like 1
  • Create New...